Refactor the API for retry options

[rylev]

This changes the API for specifying retry options to be more customizable while also being more future proof.

// Exponential retry with 10 total retries and an initial delay of 1 second
 let options = ClientOptions::default().retry(RetryOptions::exponential(
            ExponentialRetryOptions::default()
                .max_retries(10u32)
                .initial_delay(Duration::from_secs(1)),
        ));

// No retry
let options = ClientOptions::default()
     .retry(RetryOptions::none());

Note: the default remains an exponential strategy which should be appropriate for a vast majority of users. Therefore, these APIs will likely only be used by users with very specific needs.

Instead of RetryOptions being a transparent struct whose fields the user sets directly (thus making it impossible to extend in the future in a backwards compatible way), the options are now set through methods (e.g., RetryOptions::exponential, RetryOptions::fixed, etc.).

Each of these methods takes different set of arguements that are tailored just to the retry strategy at hand. Instead of requiring that the user be confronted with options that might not be relevant to their strategy of choice (e.g., the max_delay field had no meaning if the user was using a fixed retry strategy), the options are constrained just to the options that are relevant.

This does make instantiation ever so slightly more verbose as you cannot set options directly on the RetryOptions. Again, this is a feature not a bug since the options you want to set depend on the overall strategy you choose.

Lastly, this adds an additional retry strategy of custom that allows users to feed in their own Arc<dyn RetryPolicy>.

Closes #1049

[bmc-msft]

This is a positive step forwards.

It might be beneficial for usability reasons to create From<ExponentialRetryOptions> for RetryOptions (and the like for others).