Add support for Azure DNS Provider **in another tenant**

[JohnLBevan]

Is your feature request related to a problem? Please describe.
The Azure DNS provider is designed to use the AcmeBot's function's managed identity to authenticate against the DNS zone it's using for the DNS challenge.
We have a scenario where our company is splitting off some business units, so they're migrating to a new Azure tenant, taking some sites & domains with them; but migrating things over time.
With AWS R53 zones we've been able to setup 2 IAM users; one for us and one for them, so we can both use AcmeBot to manage challenges in the same zone and thus not have to plan timings of when the domains will be migrated / just focus on moving sites over.
However, for domains hosted in Azure, AcmeBot can only manage domains in the same tenant, so we're having to ensure that we migrate all sites on a given domain and the DNS zone for that domain in a <60/90 day window to ensure the cert can be managed in the new solution once the sites are there / that we can drop the cert & domain fom our instance before it needs to be renewed.

Describe the solution you'd like

• A service principal (Entra App Registration) could be created on the DNS tenant's side and granted DNS Contributor rights on the DNS Zones it should manage.
• That SP could have the AcmeBot function app's managed identity (from the other tenant) added as a federated credential. See workload identity federation for more on this - it's similar to using an SP's credentials, but avoids the need to manage credentials/certificates from the client side.
• Instead of just giving a subscription id, there could be an option to also include a tenant id, allowing queries against the remote tenant's subscription's resources.
• It's possible that a zone for the same domain may appear in both tenants (likely in migration scenarios), so tha may add some complexity. Querying public DNS NS records for the zone to see which of these zones is live/public is one solution to disambiguate; as we likely don't care which zone is chosen beyond knowing it's the zone that LetsEncrypt can see.

Describe alternatives you've considered
Any of:

• Writing a custom provider for this scenario.
• Writing scripts to automate copyiing certificates between the tenant's key vaults so we can enable/disable acmebot for a domain based on where it's live, but have the certificate from the tenant where the domain is live replicated to the tenant where it's not.
• Force renew the certificate befoe we start migrating things, migrate DNS to the remove solution and start AcmeBot there to create their cert, then get all sites under this domain migrated in the 60-90 day window before we need to renew/the original tenant's cert expires.
  All are valid options, but having OOTB support for such scenarios would be easier.
• Use a different DNS provider (e.g. AWS R53) for the duration of the migration so both tenants can manage their own certs, then migrate the domain to the new Azure tenant once the rest of the migration's completed and it's no longer required in the original.

Additional context
This isn't a priority - we can plan our work and use workarounds to avoid this being an issue; but suggesting as a feature now we've spotted this use case.