Add SignatureValidatorWithToken delegate with opt-in/decline pattern

[iNinja]

Summary

Introduces a new signature validation delegate that allows callers to either handle signature validation in full or decline, letting the handler fall through to its built-in logic.

This replaces the approach in the abandoned PR #3483, which risked recursive loops when the delegate needed to fall back to default validation.

New public API

SignatureValidationDelegateResult (readonly struct)

• Success(SecurityToken token) — delegate handled validation successfully
• NotHandled — delegate declines; handler proceeds with default logic
• If the signature is invalid, the delegate throws (e.g. SecurityTokenInvalidSignatureException)

SignatureValidatorWithToken (delegate)

public delegate SignatureValidationDelegateResult SignatureValidatorWithToken(
    SecurityToken token,
    TokenValidationParameters validationParameters,
    BaseConfiguration configuration);

TokenValidationParameters.SignatureValidatorWithToken (property)

Behaviour

1. Existing SignatureValidator / SignatureValidatorUsingConfiguration delegates retain absolute priority
2. If neither is set, SignatureValidatorWithToken is evaluated
3. If the new delegate returns NotHandled, the handler validates the signature using its default logic as if no delegate were set
4. If the new delegate returns Success, the validated token is used directly

Additional fix

BaseConfiguration is now correctly forwarded to SignatureValidatorUsingConfiguration and IssuerSigningKeyValidator in the delegate code path (previously passed as null).

Tests

14 new tests covering:

• Delegate handles / declines / throws
• Old delegate priority
• Configuration passthrough
• Telemetry (success and failure)
• Struct contract (NotHandled, Success, null guard)
• Copy constructor propagation

All 671+ existing tests pass across all 6 TFMs (net462, net472, net6.0, net8.0, net9.0, net10.0).

[iNinja]

Abandoning in favour of the approach introduced in #3489