CXF-9032 - Fix JWS verification with a "jwk" key store

[coheigea]

Two problems in JwsUtils.loadSignatureVerifier when
rs.security.keystore.type is "jwk":

1. An incoming JWS with an x5c, x5t or x5t#S256 header caused CXF to try
   to load a Java KeyStore of type "jwk" to resolve the certificate,
   which fails ("jwk KeyStore not available"). Tokens from Microsoft
   Entra ID, which carry x5t, could therefore never be verified. These
   headers are now ignored for a jwk key store and the verification key
   is loaded from the configured JWK set.
2. The kid from the JWS header was only used to select a key from the
   JWK set if rs.security.accept.public.key was enabled, a flag that
   also allows a JWK embedded in the token to be trusted. Without it, a
   key set holding several keys, such as an identity provider's JWKS,
   could not be used, and keys could not be rotated.
   When no rs.security.keystore.alias is configured, the kid now selects
   the key from the JWK set, provided the key is explicitly marked for
   signatures ("use": "sig", or key_ops containing "verify"). Otherwise
   the previous behaviour applies:
   • a configured alias still pins the verification key;
   • with accept.public.key enabled, the kid selects any key as before;
   • a kid that does not select a key falls back as before.
     To follow an identity provider's key rotation, configure a jwk key
     store pointing at its JWKS URL and no alias. Note that a valid
     signature from a shared JWKS does not mean the token was issued for
     this service: claims such as iss and aud must still be validated.