Investigate the use of ResilienceStrategy<T> as core abstraction

[martintmk]

Currently, the Polly V8 core is based around non-generic ResilienceStrategy. The reasoning behind this is detailed here.

I would like to investigate the possibility of the core to be based around generic ResilienceStrategy<T>.

One major benefit it would bring is that we would not be able to combine unsupported strategies. For example, combining ResilienceStrategy<string> with ResilienceStrategy<double> which is allowed now on the lower-level although not by public API.

The idea is that non-generic resilience strategies will be just simple wrapper over ResilienceStrategy<object>. The public API will stay virtually unchanged. The only difference is that custom strategies will now derive from ResilienceStrategy<T> instead of ResilienceStrategy.

I am also curious about the performance impact of this change and how difficult it will be to combine non-reactive with reactive strategies. Based on this experiment we may decide to switch to generic core.

[martintmk]

After investigating the generic strategies (see #1461), I've concluded that we should continue using the current non-generic approach. Compared to the generic core, our current method is less constrained. Furthermore, given the recent advancements in type-safety for reactive strategies (see #1462), our current design doesn't seem to have any significant drawbacks. The observations and decisions mentioned here are still valid.

Notes about current design:

1. It's not possible to combine incompatible reactive strategies.
2. Both reactive and non-reactive strategies have clear representations.
3. With just a single extension, non-reactive strategies can target both generic and non-generic builders.
4. The API provides an accurate representation of non-reactive strategies.
5. Combining non-reactive strategies with reactive ones is straightforward.
6. Implementing reactive strategies remains straightforward.

Switching to generic core would have negative impact on points 2, 3, 4, 5 while it would remain same for point 1.

@martincostello, @joelhulen, @vany0114