#1844 More open customization of Polly use

[RaynaldM]

In certain contexts, we need to be able to fully tune the way Polly is used for timeouts and circuit-breakers, but not only that. With this in mind, I'm proposing in this PR to open up the use of AddPolly by adding :

public static IOcelotBuilder AddPolly<T>(this IOcelotBuilder builder, Dictionary<Type, Func<Exception, Error>> errorMapping)
     where T : class, IPollyQoSProvider<HttpResponseMessage> =>
     AddPolly<T>(builder, GetDelegatingHandler, errorMapping);

 public static IOcelotBuilder AddPolly<T>(this IOcelotBuilder builder, QosDelegatingHandlerDelegate delegatingHandler)
     where T : class, IPollyQoSProvider<HttpResponseMessage> =>
     AddPolly<T>(builder, delegatingHandler, ErrorMapping);

 public static IOcelotBuilder AddPolly<T>(this IOcelotBuilder builder)
     where T : class, IPollyQoSProvider<HttpResponseMessage> =>
     AddPolly<T>(builder, GetDelegatingHandler, ErrorMapping);

Thanks to this, we will be able to use our own implementations of IPollyQoSProvider<HttpResponseMessage>, QosDelegatingHandlerDelegate and Dictionary<Type, Func<Exception, Error>>

[raman-m]

@ggnaegi FYI Easy to review, but it is marked for Dec'23 release...

[raman-m]

@RaynaldM Thanks for the PR! New extensions will be useful. Why not to test them somehow?

[raman-m]

@ggnaegi Please review!

[raman-m]

But the build is still 🔴

[raman-m]

@RaynaldM Is your development finished here?

[raman-m]

🤕

[raman-m]

If you love to press GitHub buttons then I'm letting you to finish your PR. Please fix compilation errors!

[raman-m]

My understanding this PR should be merged first before #1914 ... right?

[RaynaldM]

My understanding this PR should be merged first before #1914 ... right?

Exactly, it is an intermediate step