Fixes #43583.

This PR is about

1) Avoiding an internal ID token verification when `JsonWebToken` injected by mistake but `not accessed` from the code, even if the OAuth2 providers return binary/opaque access tokens

2) Users getting a correct error message when they attempt to access the access token using `JsonWebToken` API but the OAuth2 providers return opaque/binary access tokens

For example, in case of Github, when they have

```
class GithubService

{ @Inject JsonWebToken jwt; }

```
then any method which attempts to access the Githib binary access token as `jwt`, will get, instead of the confusing error such as:

```
2024-09-27 16:21:07,764 ERROR [io.qua.oid.run.CodeAuthenticationMechanism] (vert.x-eventloop-thread-2) ID token verification has failed:
Token issued to client 686026e8cf211de572f8 can not be introspected because the introspection endpoint address is unknown - please check if your OpenId Connect Provider supports the token introspection
```

a more appropriate, here in devmode:
```
Exception in GithubService.java:26
24 @Path("/login")
25 public String userinfo()

{ → 26 return jwt.getName() + userInfo.getUserInfoString(); 27 }

28

The stacktrace below has been reversed to show the root cause first. [See the original stacktrace](http://localhost:8080/login)

io.quarkus.oidc.OIDCException: Opaque access token can not be converted to JsonWebToken
at io.quarkus.oidc.runtime.OidcJsonWebTokenProducer.getTokenCredential(OidcJsonWebTokenProducer.java:67)
```

It will make it possible nearly immediately identify the problem which is about the user attempting to use a wrong API to access the binary token. Unfortunately we can't detect it at build time, for ex, we know, Github returns binary access tokens, but this is not part of any contract, the format can change any time.

So PR just makes sure that a check for a self-signed ID token is done correctly in both of the code branches where an ID tokne verification is attempted, with and without the initial code flow access token verification.

The added test confirms that, with a provider returning an opaque access token (value = `alice` - to match the OidcWiremock stub rule), the endpoint method works as expected if an inject `JsonWebToken` is not accessed, but fails with the server error otherwise.

It all may be a bit confusing, but all in all, it is really about improving the user experience when they make a mistake with trying to access opaque access tokens as JSON web tokens. The fix is very simple - encapsulate the code which checks how to proceed with the ID token verification into a utility method and call it from both places where it is necessary