Implementors of `IResourceWithAzureFunctionsConfig` should set additional params for identity-based configuration.

### Is there an existing issue for this?

- [x] I have searched the existing issues

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

Aspire will set `AZURE_CLIENT_ID` to inform connections of the client ID to use. When exploring scale rules setup for Azure Functions, it appears that KEDA is one example of a component that doesn't process `AZURE_CLIENT_ID` yet.

### Describe the solution you'd like

Functions also offers a combination of two other parameters, and this is the typical recommendation for setting up connections with a user-assigned identity: `__credential` (always set to "managedidentity") and `__clientId` (set to the client ID). These are documented [here](https://learn.microsoft.com/azure/azure-functions/functions-reference?pivots=programming-language-csharp#common-properties-for-identity-based-connections).

This combination of settings should be valid for all existing implementers of `IResourceWithAzureFunctionsConfig`, but this should be approached on a case-by-case basis.

There's a bit of repetition and verbosity here, but it ensures the components will work as expected. Longer-term, KEDA could be updated to process `AZURE_CLIENT_ID`, and we could explore removing some of the repetition if needed.

### Additional context

Triggers and bindings will _mostly_ be set up to consume `AZURE_CLIENT_ID`, but there may be some variance in the overall config approach. Ensuring we capture a complete setup within each `IResourceWithAzureFunctionsConfig` will improve resilience to this.

This would also be preferable if there were to be support for multiple identities in the distributed application.

Note that these settings should be set together. Setting only one will not have the desired effect. Today, the integration uses `DefaultAzureCredential`, which during probing picks up `AZURE_CLIENT_ID` to use for MI. Just setting the connection-level client ID would be ignored. By setting the credential property, though, we force the system to instead use `ManagedIdentityCredential`, and without the client ID setting, it would just attempt to resolve a system-assigned managed identity, which would not exist in normal Aspire configurations.