Add success and failure handlers to code grant filter

[prasanna164-code]

Adds AuthenticationSuccessHandler and AuthenticationFailureHandler support to OAuth2AuthorizationCodeGrantFilter, following the structure of OAuth2AuthorizationCodeGrantWebFilter, so that the outcome of the Authorization Code grant can be customized, for example to forward into the application instead of redirecting.

Filter

• setAuthenticationSuccessHandler: invoked with the OAuth2AuthorizationCodeAuthenticationToken after the OAuth2AuthorizedClient has been saved. The default preserves the existing behaviour: redirect to the saved request if present, otherwise to the redirect_uri of the OAuth2AuthorizationRequest. setRequestCache keeps its contract and feeds the default handler.
• setAuthenticationFailureHandler: invoked with an OAuth2AuthenticationException wrapping the OAuth2AuthorizationException from the AuthenticationManager. The default preserves the existing redirect to the redirect_uri with error, error_description and error_uri appended.
• RedirectStrategy and RequestCache remain private to the default handlers; no public API is removed or deprecated.

DSL and docs

• OAuth2ClientConfigurer.AuthorizationCodeGrantConfigurer and the Kotlin AuthorizationCodeGrantDsl expose authenticationSuccessHandler and authenticationFailureHandler; the XML namespace gains authentication-success-handler-ref and authentication-failure-handler-ref on authorization-code-grant, so all three configuration styles offer the same options for this element.
• New "Handling the Authorization Response" section in the servlet OAuth2 client "Authorization Grant Support" page, with Java, Kotlin and XML examples.

Tests

• OAuth2AuthorizationCodeGrantFilterTests: null checks for both setters, custom success handler receives the token and suppresses the redirect while the authorized client is still saved, ForwardAuthenticationSuccessHandler forwards, custom failure handler receives the wrapped exception with the original OAuth2Error.
• OAuth2ClientConfigurerTests, AuthorizationCodeGrantDslTests and OAuth2ClientBeanDefinitionParserTests: both handlers wired through the Java DSL, the Kotlin DSL and XML.
• Existing redirect and request-cache tests are unchanged.

Closes gh-11069

[prasanna164-code]

A few notes on the choices here, in case they come up in review:

• Default success handler. The plan in the issue suggested initialising the field to SavedRequestAwareAuthenticationSuccessHandler. I used a private default instead, because that handler falls back to its defaultTargetUrl (/) when there is no saved request, while this filter currently redirects to the redirect_uri of the OAuth2AuthorizationRequest. The private default keeps today's behaviour, and setRequestCache still feeds it as in the reactive filter.
• Default failure handler. OAuth2AuthorizationCodeGrantWebFilter rethrows by default. Here the default keeps the current servlet behaviour of redirecting to the redirect_uri with error, error_description and error_uri, so existing applications are unaffected.
• Ordering. The reactive filter invokes the success handler before saving the OAuth2AuthorizedClient; this filter saves first and then invokes the handler, which keeps the existing order and lets a forwarded request read the authorized client.

Happy to change any of these if you would rather match the reactive filter exactly.