[Proposal]: Resilience extensions - Clone HttpRequestMessage in AddStandardResilienceHandler for Retries

### Summary
Currently, the `AddStandardResilienceHandler` in the .NET extensions does not clone the outgoing `HttpRequestMessage` before performing a retry. This behavior differs from the `AddStandardHedgingHandler`, which clones the request prior to hedging. This proposal suggests modifying the resilience handler to clone the request before each retry attempt, aligning its behavior with best practices and the hedging handler.

### Problem Description
When a retry is executed without cloning the original HttpRequestMessage, the same instance is reused. According to .NET guidelines, an HttpRequestMessage should not be reused after it has been sent. https://learn.microsoft.com/en-us/dotnet/api/system.net.http.httprequestmessage?view=net-9.0

Reusing the same instance can lead to issues such as:

- Runtime exceptions: For example, attempts to resend a disposed content stream.
- Unexpected behavior: The request state might have been modified after the initial send, like headers modified, etc., leading to potential inconsistencies or errors during subsequent retries.

This can result in failures that are hard to diagnose, especially in resiliency scenarios where retries are expected to transparently recover from transient faults.

### Suggested Changes
Clone Request: Modify the `AddStandardResilienceHandler` to clone the `HttpRequestMessage` prior to executing a retry. This should be similar to the cloning approach used in `AddStandardHedgingHandler`, or even better, we can expose a delegate function to users to allow them provide the clone logic.