SecurityPolicy: Support Azure Workload Identity Federation for OIDC clientSecret

### Description:
Today, SecurityPolicy's oidc.clientSecret only supports a reference to a static Kubernetes Secret.

There's no way to authenticate the OIDC relying-party flow against Azure AD / Entra ID using Azure Workload Identity Federation instead of a client secret.

I'd like to request native support for Azure Workload Identity as an alternative credential source for oidc.clientSecret.

### Motivation

- Eliminates the need for a stored secret entirely. With Workload Identity Federation, the Envoy Gateway pod exchanges its own projected Kubernetes ServiceAccount token (an OIDC token) for a short-lived Azure AD access/assertion token via a Federated Identity Credential.
There is no client-secret value to generate, store in a Secret, rotate, or leak.

- It's the modern, cloud-native standard.

### Multiple federated identities on a single pod

One important requirement: a single Envoy Gateway (or its OAuth2 filter) pod needs to be able to use more than one federated identity e.g. one SecurityPolicy/OIDC config per tenant, app, or namespace, each backed by a different Azure AD App Registration / Managed Identity, all serviced from the same gateway deployment.

I don't know the exact implementation "magic" required on the Envoy Gateway side, but Azure Service Operator (ASO) already solves this exact problem and could be a useful reference:

- Azure Service Operator (ASO) runs as a single operator pod, but rather than reusing one shared ServiceAccount token for every tenant/identity (which ASO itself flags as a privilege-escalation risk — see their [ADR on secure Workload Identity multitenancy](https://azure.github.io/azure-service-operator/design/adr-2026-07-secure-workload-identity-multitenancy/)), their proposed approach uses the Kubernetes TokenRequest API to mint short-lived tokens for additional, per-namespace ServiceAccounts on demand.
- Each Azure Managed Identity's Federated Identity Credential trusts a specific ServiceAccount subject (e.g. system:serviceaccount:team-a:aso-workload) rather than a single shared one.
- This lets the same pod broker access to N different Managed Identities: it just requests a token for whichever ServiceAccount subject that identity's FIC actually trusts, instead of presenting the same token everywhere.

Mapped to Envoy Gateway, this suggests the "multiple identities per data-plane pod" problem may need something similar under the hood, the Envoy Proxy pod (or its sidecar/init mechanism) requesting distinct ServiceAccount tokens via the TokenRequest API per SecurityPolicy, rather than relying on the pod's single default projected token for every OIDC config.

Proposed API shape:
```
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
name: oidc-example
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: HTTPRoute
name: myapp
oidc:
provider:
issuer: "https://login.microsoftonline.com//v2.0"
clientID: "${CLIENT_ID}"
clientCredential:
type: AzureWorkloadIdentity
azureWorkloadIdentity:
azureClientID: "${MANAGED_IDENTITY_CLIENT_ID}"
tenantID: "${AZURE_TENANT_ID}"
redirectURL: "https://www.example.com:8443/myapp/oauth2/callback"
```

(Keeping clientSecret as-is for backwards compatibility, and adding a new mutually-exclusive clientCredential/similar field for federation-based auth.)

**Alternatives considered**
Using something like External Secrets Operator to sync a workload-identity-fetched secret from Key Vault into a static k8s Secret, then referencing that via the existing clientSecret field. This works today but it doesn't get you the "no secret at all" property.

**Note on other clouds**
A similar pattern would make sense for GCP & AWS. Happy to see this generalized if maintainers want a common abstraction, but I don't have concrete requirements or input for those, so this request is scoped to Azure only.

**Additional context**
Azure Workload Identity docs: https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview
ASO auth docs: https://azure.github.io/azure-service-operator/guide/authentication/

Start by reviewing SecurityPolicy's existing oidc.clientSecret API and the Azure Workload Identity and Azure Service Operator authentication references linked in the issue. Done means defining Azure federation support while preserving clientSecret compatibility, supporting multiple federated identities per pod, and documenting or testing the proposed configuration.

Written by the indexing model from the issue text.