Support development time TokenCredential

### Description

To improve local development, core-tools should offer a way to support development time `TokenCredential`.

### Background

Today Azure Functions supports credential via configuration. The exact credentials supported is intentionally aligned with what Azure SDK supports via `AzureComponentFactory.CreateTokenCredential`. This works for scenarios but is limiting for local development. The only local dev route is to 'trick' it into giving you a `DefaultAzureCredential`, and then _hoping_ that resolves to the dev credential you want.

That later part is a challenge when you are developing on a machine with higher precedence credentials that you do not want to use (such as a valid managed identity endpoint).

### Plan

We will add support to core tools to inject a custom `ChainedTokenCredential` for the host which includes only common dev-time credentials in it (exact creds TBD, but current theory is everything from [DefaultAzureCredential](https://learn.microsoft.com/en-us/dotnet/api/azure.identity.defaultazurecredential?view=azure-dotnet) less managed identity credential).

Injecting of the credential will be done via setting a global default credential with the `.AddAzureClients()` call:

``` CSharp
services.AddAzureClients(b => b.UseCredential(/* dev time credential */));
```

### Design Needed

1. What is the opt-in mechanism for customers is here?

### Known Limitations

The mechanism this relies on is how [AzureComponentFactoryImpl](https://github.com/Azure/azure-sdk-for-net/blob/6d246a4976c6cd9982660f90d796a9fcac11ee97/sdk/extensions/Microsoft.Extensions.Azure/src/Internal/AzureComponentFactoryImpl.cs#L26) will fall back to `_globalOptions.CurrentValue.CredentialFactory(_serviceProvider);` when the `ClientFactory.CreateCredential` returns `null`. This poses two known limitations:

1. Whatever we do here will not take precedence over `ClientFactory.CreateCredential`, as it runs first. So if a customer has valid credential config for a trigger, that will preferred over the global dev credentials.
2. In the same theme, there will be no way to configure per-trigger dev credentials. There will only be one global dev credential
3. Not all extensions use `AzureComponentFactory`. These will not be in-scope for this work.

# Related Issues
https://github.com/Azure/azure-functions-dotnet-worker/issues/3027

Start by reading the issue plan and related issue 3027, then inspect AzureComponentFactoryImpl and the AddAzureClients().UseCredential() entry point linked here. Resolve the opt-in mechanism and which development credentials are included, accounting for configured per-trigger credentials and extensions outside AzureComponentFactory. Done means core-tools can provide the agreed global development credential behavior.

Written by the indexing model from the issue text.