[Feature] Support SASL/OAUTHBEARER authentication for Fluss RPC

## Search before asking

- [x] I searched in the issues and found nothing similar.

## Motivation

Fluss currently supports pluggable authentication and built-in SASL/PLAIN
authentication. In many production environments, service identity is managed through
OAuth2/OIDC providers and clients authenticate with bearer tokens, usually JWTs.

It would be useful for Fluss to support the standard SASL/OAUTHBEARER mechanism
in the native Fluss RPC authentication layer. This would allow clients to
authenticate with OAuth bearer tokens, and allow Fluss servers to validate those
tokens and map validated claims to `FlussPrincipal` for the existing ACL authorization flow.

This feature can be designed to work together with [FIP-29: (m)TLS Support](https://cwiki.apache.org/confluence/display/FLUSS/FIP-29%3A+%28m%29TLS+Support). FIP-29 keeps transport security and authentication orthogonal: TLS protects
the transport, while `client.security.protocol` and `security.protocol.map` select the authentication protocol. Following that model, OAuth bearer token
authentication should be introduced as a SASL mechanism.

## Solution

Add support for `OAUTHBEARER` as a SASL mechanism:

```properties
client.security.protocol=SASL
client.security.sasl.mechanism=OAUTHBEARER
```

Server-side example:

```yaml
security.protocol.map: CLIENT:SASL
security.sasl.enabled.mechanisms: OAUTHBEARER
security.sasl.oauthbearer.jwks.endpoint.url: https://issuer.example.com/.well-known/jwks.json
security.sasl.oauthbearer.expected.issuer: https://issuer.example.com
security.sasl.oauthbearer.expected.audience: fluss
security.sasl.oauthbearer.principal.claim.name: sub
```

Proposed implementation direction:

- Refactor the current SASL implementation so SASL mechanisms are extensible
instead of hard-coding only `PLAIN`.
- Preserve existing SASL/PLAIN behavior and compatibility.
- Add an `OAUTHBEARER` mechanism for the native Fluss RPC authentication layer.
- Add client-side token provider support.
- Add server-side JWT/JWKS token validation.
- Validate token signature, issuer, audience, expiration, not-before, and
configurable clock skew.
- Map a configurable token claim to `FlussPrincipal`.
- Reuse the existing ACL authorization flow after authentication succeeds.
- Add tests for successful authentication, invalid token, expired token, wrong
issuer, wrong audience, and principal mapping.

When TLS support from FIP-29 is available, users can run SASL/OAUTHBEARER over
TLS by enabling TLS separately. When OAUTHBEARER is used without TLS, the
implementation may log a warning but will honor the configured transport.

## Implementation plan

The implementation will be split into incremental PRs:

- [ ] Phase 1: Make the existing SASL layer mechanism-extensible while preserving
SASL/PLAIN behavior. See #3865.
- [ ] Phase 2: Add OAUTHBEARER client token acquisition/cache and server-side
JWT/JWKS validation. See #3978

Listener-specific SASL enabled mechanisms are tracked separately by #3858 and are not part of this issue's implementation scope.

Each network connection keeps an independent authenticator. Token and JWKS
resources may be shared across connections within their owning client/server.
The authentication protocol remains synchronous and does not require protobuf
changes.

## First-version scope

- Support JWT/JWKS validation; token introspection is out of scope.
- Provide a built-in OAuth2 Client Credentials token provider.
- Allow OAUTHBEARER without TLS and log a warning when appropriate.
- Map the validated `sub` claim to the primary user principal. Group-based ACL
authorization is tracked by #3829.

Related design: [FIP-29: (m)TLS Support](https://cwiki.apache.org/confluence/display/FLUSS/FIP-29%3A+%28m%29TLS+Support)

## Willingness to contribute

- [x] I'm willing to submit a PR!

Start by reading the Phase 1 issue, #3865, and the Phase 2 issue, #3978, since this work is explicitly split across them. Completion requires extensible SASL/PLAIN compatibility, OAUTHBEARER client and JWT/JWKS validation support, configurable principal mapping, and tests for successful and rejected authentication cases.

Written by the indexing model from the issue text.