[FEATURE] Add CancellationToken support to SetProviderAsync method

[kylejuliandev]

Requirements

Providers provide implementation details for initializaing the Provider. Calling SetProviderAsync on the Api will initialize the provider.

Proposed API Changes

Update the Api.SetProviderAsync(FeatureProvider) and Api.SetProviderAsync(string, FeatureProvider) methods to accept a CancellationToken parameter.

public async Task SetProviderAsync(FeatureProvider featureProvider)
public async Task SetProviderAsync(FeatureProvider featureProvider, CancellationToken cancellationToken)
public async Task SetProviderAsync(string domain, FeatureProvider featureProvider)
public async Task SetProviderAsync(string domain, FeatureProvider featureProvider, CancellationToken cancellationToken)

Additionally, we should ensure that the cancellation token is propagated through to the provider initialization logic and any asynchronous operations involved in setting or initializing a provider.

Benefits

• Graceful Cancellation: Allows consumers of the API to cancel provider initialization if the operation is taking too long or if the application is shutting down, improving responsiveness and resource management.
• Consistency: Aligns with modern .NET asynchronous programming practices, where long-running or potentially blocking operations should support cancellation.
• Testability: Makes it easier to write robust tests for scenarios where initialization may be interrupted or needs to be aborted.
• Resource Efficiency: Prevents unnecessary work and resource usage when the operation is no longer needed, especially in environments with strict resource constraints or timeouts.

Drawbacks

• API Surface Area: May require updates to documentation.
• Backwards Compatibility: While adding an optional parameter is generally safe, if any consumers are using reflection or custom method binding, they may need to be updated.

[kylejuliandev]

Updated API Proposal due to some feedback and potential concerns. Instead of updating the signature to include an optional CancellationToken parameter we will instead provide another overload with the CancellationToken. This is a safer change as the source does not change, so it will remain backwards compatiable (even for those that may be using reflection or other dynamic code gen).