[FEATURE REQUEST] SSO / Federated User/Role support

### Is your feature request related to a problem? Please describe.

User management is complicated and can scale to thousands or tens of thousands of users for large enterprises. Group membership is frequently dynamic and privileges tied to group membership needs to be able to reflect group membership changes immediately.

Large enterprises typically use identity provider services, such as Okta, LDAP, or Google, to manage users and roles. These central IdPs are typically relied upon to communicate user authentication and group membership so that an administrator needs to make changes in a single central location and know that all peripheral applications will see those changes immediately.

### Describe the solution you'd like

SSO and support for Federated Users and Federated Roles would allow defining users and roles as "federated" so that token generation and role membership is disallowed through the Polaris management APIs. I see the following changes being implemented:

1. Support for multiple `Authenticator`s to be configured - an admin could potentially have multiple IdPs that should be trusted to generate auth tokens. These tokens need to be inspected and validated in Polaris, potentially by making an API call to the IdP or by validating an encryption signature in a JWT.
2. Extending the authentication flow to support just-in-time Principal creation - when a `TokenBroker` parses a token and returns a user that doesn't have a principal entity, one should be created from the token info. The Principal should be marked as `federated` in its `internal_properties`. A `federated` Principal does not have any clientId/secret stored and cannot generate a token in the `/tokens` API.
3. Extending the authentication flow to support just-in-time PrincipalRole creation and assignment - when a `TokenBroker` parses a token, the scopes defined in the token should translate into PrincipalRole membership. These roles may not exist in Polaris, so should be created. The `AuthenticatedPrincipal` will implicitly have membership in these `PrincipalRole`s. The `PrincipalRole` should be marked as `federated` in its `internal_properties`. A `federated` PrincipalRole cannot be granted to non-`federated` Principals.
4. `federated` Principals also cannot be granted membership to a non-`federated` PrincipalRoles - the tokens generated by the IdP will never include a non-`federated` PrincipalRole, so granting membership doesn't make sense.
5. Both `federated` Principals and PrincipalRoles must have a `federation_source` - a `federated` Principal should only be granted access to PrincipalRoles that are defined for the same `federation_source`. A naming convention, such as a source prefix, should be considered to avoid name clashing of Principals and PrincipalRoles. It would be necessary to map scopes and usernames present in the token to the expected name of the created Principal/PrincipalRole.

### Describe alternatives you've considered

_No response_

### Additional context

_No response_

Start by reading the authentication flow and the TokenBroker behavior described in the issue, along with the management APIs for tokens, Principals, and PrincipalRoles. The work is done when multiple trusted authenticators, just-in-time federated entities, federation-source checks, and restrictions on token generation and role grants are defined and implemented with validation.

Written by the indexing model from the issue text.