Update quarkus-oidc-token-propagation to better work with JWT tokens and update smalrye-jwt to 2.4.4

[sberyozkin]

Fixes #15387.
Fixes #14798.

This PR has proved a bit more complex to finalize than I expected but it starts in the direction of avoiding the direct token propagation, for now with JWT-formatted tokens and in fact is quite simple. Here is what it does:

• quarkus-oidc-token-propagation now depends only on the MP JWT API and quarkus-security - it was a mistake to make it pull quarkus-oidc - as it means that for KC tokens verified by quarkus-smallrye-jwt could not be propagated. The other problem was it would not start if Keycloak were not available (as reported by @tqvarnst)
• Existing AccessTokenRequestFilter which propagates the tokens has been updated to accept Instance<TokenCredential> because 1) AccessTokenCredential is part of quarkus-oidc and without Instance it would not start if neither quarkus-smallrye-jwt nor quarkus-oidc were available
• updated quarkus-smallrye-jwt to ensure it can work with AccessTokenCredential by producing TokenCredential
• updated quarkus-oidc to ensure AccessTokenCredential is preferred to IdTokenCredential for the TokenCredential injection
• updated smallrye-jwt version to 2.4.4 as it contains a fix required for this PR
• added JsonWebTokenRequestFilter it can be registered same as AccessTokenRequestFilter, either for the specific clients or for all the clients
• updated the docs which recommend when to use which filter
• updated the existing integration-tests/oidc-token-propagation (which uses quarkus-oidc) to ensure both filters can handle the tokens
• added a new integration-tests/smallrye-jwt-token-propagation test - this is the first integration test which will stress both the server and client smallrye-jwt code in the native mode - and here it is tested how smallrye-jwt can use Keycloak certs to verify its tokens and to show how JsonWebTokenRequestFilter can update these tokens with the new issuer and audience and re-sign (or later - sign/encrypt).

After this PR the next step would be to use a Keycloak token exchange grant to support exchanging the tokens via Keycloak

[gastaldi]

LGTM

[sberyozkin]

@gastaldi thanks George, will wait for Pedro as well

[sberyozkin]

@pedroigor thanks Pedro - I'm committed to wiring in the exchange protocol into AccessTokenRequestFilter - will be pinging you for sure about it :-), and the exchange protocol solution will be recommended instead of the one offered in this PR - which will only be the option for the users who can't use the exchange protocol or for the users who write the endpoints interposing over KC and acting as the issuers - I've seen a user discussion about the latter case.
Thanks