Expose --audience flag as configurable Helm value

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

I'm running Azure Workload Identity on a self-managed Kubernetes cluster and need to use a custom audience value (for example `some-domain.com`) instead of the default `api://AzureADTokenExchange`.

This is necessary because we use the same OIDC issuer for multiple cloud providers (AWS, Azure, GCP) and want a neutral audience that works across all of them.

Currently, the `--audience` flag exists in the webhook code under `cmd/webhook/main.go` but is not exposed as a configurable Helm chart value. Thus, the webhook always injects projected service account tokens with the hardcoded default audience `api://AzureADTokenExchange`, even when:
- The K8s API server is configured with a custom `--api-audiences` value
- The Azure federated identity credential is configured to accept the custom audience

I get `Microsoft Entra ID error (invalid_client) AADSTS700212: No matching federated identity record found for presented assertion audience 'api://AzureADTokenExchange'. Please check your federated identity credential Subject, Audience and Issuer against the presented assertion` which is a common error in other issues but none of those issues was related to audience (all of them set the audience to `api://AzureADTokenExchange`, even the Azure documentation says it is recommended to use that expected audience)

**Describe the solution you'd like**

Add an `audience` field to `values.yaml` that gets passed as the `--audience` flag to the webhook deployment (default to `api://AzureADTokenExchange`)

**Describe alternatives you've considered**

1. Manually patching the deployment:
```bash
kubectl edit deployment azure-wi-webhook-controller-manager -n azure-workload-identity-system
# Manually added --audience=another-domain.com to args
```
It does work. However, this is a temporary solution as it will be lost on helm upgrades

2. Manually specifying projected token volumes in each pod (in other words: not using the webhook):
```yaml
volumes:
- name: azure-identity-token
projected:
sources:
- serviceAccountToken:
audience: another-domain.com
```
That defeats the purpose of using the webhook + it must be repeated in every pod spec

3. Forking and maintaining a custom chart: That's the way to go for now, but it's still preferred to add this feature to the project so that it's maintained and others could benefit from it

**Additional context**

- The `charts/workload-identity-webhook` README states that:

> Helm chart is autogenerated from the Azure AD Workload Identity static manifest. The generator code lives under `third_party/open-policy-agent/gatekeeper/helmify`. To make modifications to this template, please edit `kustomization.yaml`, `kustomize-for-helm.yaml` and `replacements.go` under that directory and then run make manifests. Your changes will show up in the `manifest_staging` directory and will be promoted to the root `charts `directory the next time an azure-workload-identity release is cut.

- This feature would align with similar patterns in AWS IRSA and GCP Workload Identity where audiences are configurable
- The [Azure documentation](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust?pivots=identity-wif-apps-methods-azp#:~:text=The%20recommended%20value%20is%20%22api%3A//AzureADTokenExchange%22) states that `api://AzureADTokenExchange` is recommended (didn't state it's a must). Thus, custom audiences should logically be supported as long as they match between the token and the federated credential
- Multi-cloud environments are increasingly common and a configurable audience simplifies OIDC federation management across providers

I'm happy to submit a PR if this feature aligns with the project's goals. Otherwise, if there are reasons it is hardcoded to `api://AzureADTokenExchange` and this was intentional, I'm curious to know why

Start with cmd/webhook/main.go and the Helm chart values and deployment templates. Read kustomization.yaml, kustomize-for-helm.yaml, and replacements.go under third_party/open-policy-agent/gatekeeper/helmify, then run make manifests. Done means an audience value defaults to api://AzureADTokenExchange and is passed to the webhook as --audience in the generated chart.

Written by the indexing model from the issue text.