Fix parametersConverters nullability in AbstractRestClientOAuth2AccessTokenResponseClient

AbstractRestClientOAuth2AccessTokenResponseClient has the following methods:

• setParametersConverter(Converter<T, MultiValueMap<String, String>> parametersConverter)
• addParametersConverter(Converter<T, MultiValueMap<String, String>> parametersConverter)

When I want to configure a RestClientClientCredentialsTokenResponseClient which extends AbstractRestClientOAuth2AccessTokenResponseClient with a NimbusJwtClientAuthenticationParametersConverter, I get jspecify warnings because NimbusJwtClientAuthenticationParametersConverter implements Converter<T, @Nullable MultiValueMap<String, String>>.

So AbstractRestClientOAuth2AccessTokenResponseClient.addParametersConverter() expects a Converter<T, MultiValueMap<String, String>> while NimbusJwtClientAuthenticationParametersConverter is a Converter<T, @Nullable MultiValueMap<String, String>>. The only difference is the @Nullable on the MultiValueMap.

I think AbstractRestClientOAuth2AccessTokenResponseClient should be adapted to use @Nullable as well as those methods check if the returned map is null anyway:

MultiValueMap<String, String> parametersToAdd = parametersConverter.convert(authorizationGrantRequest);
if (parametersToAdd != null) {
    parameters.addAll(parametersToAdd);
}

Start with AbstractRestClientOAuth2AccessTokenResponseClient and inspect setParametersConverter and addParametersConverter alongside their existing null checks. Verify that a NimbusJwtClientAuthenticationParametersConverter can be configured without jspecify warnings, and confirm the returned parameters are still handled correctly when null.