Eliminate custom bearer token format

[soxofaan]

In the openEO API spec we currently require bearer tokens of the format oidc/{provider_id}/{token} or basic//{token}:

openeo-api/openapi.yaml

Lines 6714 to 6721 in c5a45b4

	bearerFormat: >-
	The Bearer Token MUST consist of the authentication method, a provider
	ID (if available) and the token itself. All separated by a forward slash
	`/`. Examples (replace `TOKEN` with the actual access token): (1) Basic
	authentication (no provider ID available): `basic//TOKEN` (2) OpenID
	Connect (provider ID is `ms`): `oidc/ms/TOKEN`. For OpenID Connect, the
	provider ID corresponds to the value specified for `id` for each
	provider in `GET /credentials/oidc`.

My view is a bit limited and openEO biased, but it seems there is growing convention to use a JWT access token as bearer token in the Authorization header, and authentication/authorization related tooling (e.g. security/authorization gateways) builds on that assumption.
The custom prefix format we currently use of course conflicts with that.
I wonder if we can figure something out to make the openEO API more compatible with that assumption/convention.

e.g.:

• if basic auth is disabled and there is only one OIDC provider active: it's allowed to omit the prefix
• split off the method and OIDC provider to a different request header

This would clearly be a breaking change, so not something in scope of the standard openEO API spec v1.x.
But maybe it could be an optional extension in some way.

(This came up again in another EOEPCA meeting, so I though it would be good to kick off some discussion here or at least have a pointer to that aspect)

[m-mohr]

We could actually try to migrate slowly to it (optionally adding it, deprecating the other approach, indicate availability via conformance classes), making the whole thing a bit more aligned with the rest of the World ;-)

• Add conformance classes for OIDC, HTTP Basic, JWT Web Tokens, custom openEO tokens
• Deprecate (for this purpose) the endpoints list in favor of conformance classes (see also Conformance classes instead of endpoint list #506)
• Deprecate custom openEO tokens and document how to use JWT tokens instead

This could all be done in a v1.x.0. Backends would need to support both variants for some time while the clients migrate...