Support ServiceAccount-based identity for ACME DNS01 solvers

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

The cert-manager controller's ServiceAccount often needs access to external DNS infrastructure when using ACME DNS01 challenges.

With workload identity, this can mean granting the cert-manager ServiceAccount permission to modify DNS zones. In a multi-tenant cluster, this can give the controller access to DNS infrastructure unrelated to a particular Issuer.

Several DNS providers already support workload identity, and cert-manager already has a similar mechanism in the Route53 solver.

Describe the solution you'd like

Allow a DNS01 solver to specify a ServiceAccount whose identity should be used when accessing the DNS provider:

solvers:
- selector:
    dnsZones:
    - example.com
  dns01:
    serviceAccountRef:
      name: dns01
    azureDNS:
      ...

cert-manager would use the Kubernetes TokenRequest API to obtain a short-lived bound ServiceAccount token for the referenced ServiceAccount. This is the same type of token commonly used as a projected ServiceAccount token for workload identity.

The token can then be exchanged with the provider's workload identity mechanism, without granting the cert-manager controller's own ServiceAccount access to the external infrastructure.

The namespace should be implicit:

• For an Issuer, the ServiceAccount must be in the Issuer's namespace.
• For a ClusterIssuer, the ServiceAccount must be in the cert-manager cluster resource namespace.

Arbitrary cross-namespace ServiceAccount references should not be allowed.

RBAC would be explicitly granted by the cluster administrator when configuring the Issuer, for example:

rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  resourceNames: ["dns01"]
  verbs: ["create"]

This keeps the cert-manager controller from needing the external DNS permissions itself.

The Route53 solver already supports a ServiceAccount reference for AWS web identity authentication and obtains a bound ServiceAccount token for it. Vault also has similar TokenRequest-based authentication.

This proposal would generalize that pattern for ACME DNS01 solvers rather than requiring each provider to implement it independently.

A first implementation could:

1. Add a generic serviceAccountRef to the DNS01 solver.
2. Extract/reuse the existing bound-token/TokenRequest functionality.
3. Adapt the Route53 solver to use the generic mechanism.
4. Add support to other DNS providers that already support workload identity.

The goal is to make the identity used by a DNS01 solver independently configurable from the cert-manager controller identity, particularly for multi-tenant clusters.

Describe alternatives you've considered

We are currently running in Azure, and for for AzureDNS specifically, there isn't currently an equivalent workaround using a per-Issuer serviceAccountRef

We can create a dedicated Azure identity for DNS, but it has to be associated with the cert-manager controller ServiceAccount.

The important limitation is that all AzureDNS solvers using ambient Workload Identity effectively share that controller identity. You can select a different managedIdentity.clientID in the solver, but the workload identity token injected into the controller is still based on the controller's ServiceAccount. cert-manager's Azure implementation detects AZURE_FEDERATED_TOKEN_FILE and constructs an Azure Workload Identity credential from it.

Additional context

/kind feature