Allow custom request context in WebAuthnAuthenticationFilter via AuthenticationConverter

Expected Behavior

WebAuthnAuthenticationFilter should expose an AuthenticationConverter setter
so that applications can extract additional request context (e.g. custom JSON fields,
query parameters, or headers) and make them available during the authentication flow.

A default implementation preserves existing behavior. Custom implementations could
enrich the resulting Authentication token or store extra context as request
attributes, making them accessible to the AuthenticationSuccessHandler.

This is consistent with patterns already established in other Spring Security filters
(e.g. UsernamePasswordAuthenticationFilter, BearerTokenAuthenticationFilter).

Current Behavior

attemptAuthentication hard-codes the deserialization target to
PublicKeyCredential<AuthenticatorAssertionResponse>:

ResolvableType resolvableType = ResolvableType.forClassWithGenerics(
    PublicKeyCredential.class, AuthenticatorAssertionResponse.class);
publicKeyCredential = this.converter.read(resolvableType, httpRequest, null);

Any extra fields sent in the request body are silently dropped by Jackson.
The resulting WebAuthnAuthenticationRequestToken only carries a
RelyingPartyAuthenticationRequest (credential + options) with no room
for application-level context.

There is no hook to intercept or extend what is read from the request before
the token is built and passed to the AuthenticationManager.

Context

In a stateless passkey flow (JWT-based, no server-side session), the frontend
needs to pass additional data alongside POST /login/webauthn — for example,
a device identifier or login-context token — so that the AuthenticationSuccessHandler
can include it in the issued JWT.

The only working workaround today is URL query parameters:

POST /login/webauthn?deviceId=abc123

These are readable from HttpServletRequest in the success handler, but query
parameters appear in server access logs, which is undesirable for identifiers
that should be treated as semi-sensitive.

A custom AuthenticationConverter setter on WebAuthnAuthenticationFilter would
allow structured data to be read from the body or headers and forwarded cleanly
through the authentication flow without workarounds.

Start at WebAuthnAuthenticationFilter.attemptAuthentication and compare its request conversion with UsernamePasswordAuthenticationFilter and BearerTokenAuthenticationFilter. Trace WebAuthnAuthenticationRequestToken through the AuthenticationManager to the AuthenticationSuccessHandler, then verify that a custom AuthenticationConverter can preserve extra request context without changing default behavior.