Support attestation-based client authentication

[babisRoutis]

PR aims (hopefully) to support attestation-base client (wallet) authentication.

• [x] Introduce a sealed hierarchy named Client having two member Public and Attested. Client would express the OAUTH2 client and in particular the way that it can be authenticated to token and/or PAR endpoint
• [x] Assumed that Client.Attested has already a ClientAttestationJWT. How this is provisioned is outside the scope of the PR
• [x] Change the TokenEndPointClient to create a ClientAttestation by producing the POP JWT
• [x] Similarly, change the PAR request
• [x] Replace clientId with client in OpenId4VCIConfig
• [x] Take into account Wallet Attestation Schema from HAIP
• [x] Fix the DeferredIssuerExt.kt extensions

Closes #304

[babisRoutis]

Attestation based client authentication states that

Implementers should be aware that the design of this authentication mechanism deliberately allows for a Client Instance to re-use a single Client Attestation JWT in multiple interactions/requests with an Authorization Server, whilst producing a fresh Client Attestation PoP JWT. Client deployments should consider this when determining the validity period for issued Client Attestation JWTs as this ultimately controls how long a Client Instance can re-use a single Client Attestation JWT.

To my understanding, the highlighted phrase means that library should produce a new PoP JWT with each interaction. For instance, in a typical HAIP scenario

• Wallet will place a PAR, then
• Will get from token endpoint the access_token

Those two interactions, will use different PoP JWT, yet bound to the same client attestation JWT.