Refactor authentication provider JSON configuration

This is related to #6515, #6679 and of course #5974.

To configure an authentication provider in Dataverse, you need to send a JSON document to the Admin API. Example for OAuth2.

Within the document, the real options for your provider are encoded in a string:

"factoryData":"type: github | userEndpoint: NONE | clientId: FIXME | clientSecret: FIXME",

This is not very convenient in terms of validation, readability and extending. With upcoming changes to provide more configuration options for an authentication provider like what to override, what can be trusted etc etc, this should be changed to sth. more sophisticated.

The different providers are also very inconsistent in what you can do with them. For example, OAuth2 providers can have a customizable title, while the Shibboleth provider cannot.

I propose to switch to something like this:

{
    "id":"github",
    "type":"github",
    "enabled":true,
    "title": "GitHub",
    "description": {
       "en_US": "This is Github.",
       "de_DE": "Das ist Github."
    },
    "logo": "<base64 encoded logo>",
    "options": {
       "client_id": "my-client-id",
       "client_secret": "my-client-secret"
    }
}

Please find a complete JSON Schema (in draft-07 notation) for details, unambiguity and precision in my gist. It can be used to play for example on https://jsonschemalint.com or any other draft-07 compliant editor/validator.

Notes:

1. You might have noticed, that this includes a necessary change to AuthenticationServiceBean to change the concept of AuthenticationProviderFactory to provide a factory for every provider we offer instead of grouping the OAuth2 ones. The benefit is the reduced complexity and increased unambiguity.
2. Also removed is the subtitle option. It has never been used and should be replaced with description. That could offer a better approach for things like those we do for ORCID, but in a more general fashion and more flexible.

This is most likely to trigger the UI team, as we might decide to actually implement that description and logosupport... 😉 Triggering @TaniaSchlatter @djbrooke @scolapasta

I think this is from a technical perspective a smaller issue. It requires some refactoring, but the auth flow is untouched. It's mostly about how the configuration flies in and which providers are built.

Start with AuthenticationServiceBean and the Admin API handling for authentication-provider configuration, then compare the current factoryData format with the linked draft-07 JSON Schema. The work is done when provider configuration uses the proposed structured fields and the provider factories handle the supported providers consistently, including description and logo options.