Add support for Service Accounts authenticated through federated identity instead of long-lived static credentials like API Keys.

A Service Account should allow administrators to configure one or more trusted identity providers (OIDC issuers) together with claim validation rules (for example iss, sub, aud, or other claims). When an external identity token satisfies these conditions, Harness should exchange it for a Harness access token representing the configured Service Account.

The Harness API should also support authentication using Harness access token instead of API Key.

This would enable secure workload identity federation with external systems, cloud providers, and identity platforms without requiring stored secrets or API keys.

The token exchange mechanism should follow OAuth 2.0 Token Exchange (RFC 8693) wherever applicable.

This approach is similar to workload identity federation implemented by cloud platforms such as Microsoft Entra ID (App Registrations with Federated Identity Credentials), AWS IAM Roles for OIDC, and Google Cloud Workload Identity Federation.