[TLS] Extract SSL principal mapping (SslPrincipalMapper)

### Search before asking

- [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar.

### Description

Part of #3786 ([FIP-29: (m)TLS Support](https://cwiki.apache.org/confluence/spaces/FLUSS/pages/406620533/FIP-29+m+TLS+Support)).

**Wave 0** — no dependencies, can start immediately.

Add `SslPrincipalMapper`, a Kafka-compatible mapper from an X.500 Distinguished Name (DN) — the RFC 2253 string returned by `X500Principal.getName()` — to a principal name. This is pure string/regex logic with no SSL/TLS machinery involved, so it's fully independent of the rest of the TLS work.

- `DEFAULT` keeps the full DN as the principal name.
- `RULE:pattern/replacement/[LU]` rules extract/rewrite a DN into a shorter, stable principal (e.g. just the CN) — v1 ships `DEFAULT` plus basic extract rules; the full Kafka grammar is future work.
- Unsupported rule grammar is rejected eagerly (`IllegalArgumentException`) when parsing the rules, not silently ignored — this lets the config-validation in the server pipeline ticket fail fast at startup.
- A DN that matches no rule raises a clear, catchable error (not an internal/unchecked failure) — the mTLS ticket (#3793) wraps this into `AuthenticationException`.

New config option: `security.ssl.principal.mapping.rules` (string, default `DEFAULT`).

**Depends on:** none.
**Depended on by:** mTLS authentication plugin (#3793).

_Estimated diff size: ~250 lines._

### Willingness to contribute

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

Start with the SslPrincipalMapper entry point and the server configuration-validation path for security.ssl.principal.mapping.rules. Read the requirements for DEFAULT, basic RULE extraction, eager rejection of unsupported grammar, and the no-match error; done means those behaviors are covered and the result can be used by the mTLS ticket (#3793).

Written by the indexing model from the issue text.