[WIP] feat: file conversion provider

[elzody]

• Part of: 📄💫 File conversion #49603
• Front: feat(api): File conversion Files action #50123

Summary

This PR will introduce a file conversion API endpoint, which can be called to convert a file from one type to another. Apps can register their own conversion providers (which implement IConversionProvider), and the providers can define which MIME types they support for conversion via ConversionMimeTuples.

TODO

• OpenAPI specs
• Flesh out some more details around the IConversionProvider interface
  • What type should it really return? Stream, resource, File, file path?
• What should happen when multiple apps register similar conversion providers?
• How should we make the preferred list of conversion providers?

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[juliusknorr]

Something just came to my mind is that for integrating the user interface we may also want additional metadata for the target formats.

We can probably get the file extension from our mimetype mapping, but wondering if we need to have more details, like a display name. Similar to save dialogs that came to my mind:

[juliusknorr]

@sorbaugh Has the files team already discussed any UI parts with designers? I'd say we can start with this PR and could extend/adapt on demand later on as well.

[skjnldsv]

Ah, I literally added a similar comment eheh

Two options I think:

1. We stop using getSupportedMimeTypes and go back to a singular getSupportedMimeType, and we basically use the name, only one Provider per destination mime
2. We turn this into a mime => l10n array, so we know the end name of each mime :)

[skjnldsv]

Why is this needed?

I think the name of the end format is more relevant.