feat: Add withValidatorCustomizer to AbstractTokenAuthenticator

[NiklasHerrmann21]

Summary

Lets callers register a Consumer<JwtValidatorBuilder> that receives the internally assembled builder just before build() is invoked. Mirrors the existing withValidationListener pattern (list semantics, applied in registration order).

Why

A stakeholder needs to disable the tenant id check (JwtValidatorBuilder#disableTenantIdCheck) for their setup. Today the only way to do that is to construct their own Validator<Token> entirely from scratch, which forces them to replicate the rest of the default validator setup and to track every future change to it — adjustments that internal-only refactors would happily make without anyone downstream noticing.

The customizer-callback approach lets the library keep ownership of the default validator setup while giving callers a narrow, targeted hook to opt out of individual defaults.

Usage

new IasTokenAuthenticator()
    .withServiceConfiguration(config)
    .withValidatorCustomizer(JwtValidatorBuilder::disableTenantIdCheck);

Design notes

• Consumer<JwtValidatorBuilder> over a custom interface — standard Java functional interface, no new abstraction, lambda/method-reference at the call site.
• List semantics over single setter — consistent with withValidationListener, allows composition (e.g. a library layer and the app layer can each register their own customizer without overwriting each other).
• Customizers run after validationListeners have been registered on the builder, so a customizer can also remove/reorder listeners if it really needs to. In practice the expected use is one or two disableX() calls.

Test plan

• mvn -pl java-security -am clean test — green; IasTokenAuthenticatorTest goes from 6 → 9 tests
• mvn install -DskipTests (full repo compile) — green
• New tests cover: customizer is invoked during validator construction, multiple customizers run in registration order, null customizer is rejected

Follow-up

A separate PR will mirror this change onto main-3.x.