Implement Retry Strategy Resolver Pattern with Per-Client Caching

[SamRemis]

Summary

Introduces a resolver pattern for retry strategies that enables per-client caching and state management. This allows multiple operations from the same client to share a single retry strategy instance, which is important for strategies that maintain state across retries such as token buckets and rate limiters.

Motivation

Previously, each operation created its own retry strategy instance, preventing state sharing across operations from the same client. This change implements a resolver-based approach.

Key Changes

• Added a new RetryStrategyResolver protocol similar to AuthSchemeResolver. This will be used for objects which will supply clients with retry strategies
• Added a CachingRetryStrategyResolver which implements the protocol and returns a unique instance of a requested retry strategy object per unique combination of client, max attempts setting, and retry mode setting
• Added a CLIENT_ID property key to the context to allow the request pipeline to track the unique client object a request came from
• Updated codegen and the request pipeline to use the new RetryStrategyResolver where it had previously only used a RetryStrategy object directly
• Added RetryStrategyOptions for users to configure their retry strategy mode and max attempts per client call

Breaking Changes

Customers directly supplying a RetryStrategy object will no longer be able to do so, and will need to pass a RetryStrategyResolver instead. This is documented in the included changelog
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.