GenericTimerService: Replace dyn clock with type param.

[Dirbaio]

Currently GenericTimerService takes a &'static dyn Clock. This has the following disadvantages:

• No way to avoid dynamic dispatch
• The GenericTimerService has to store the &'static dyn Clock, which is 2 words.
• Even if you don't want the GenericTimerService to live forever, you need the Clock to be 'static anyway. This is awkward if you're making a public API that uses GenericTimerService internally, and have no 'static place to store the Clock.

This PR changes it to a type param T, and takes an owned T.

Creating a GenericTimerService with &dyn Clock or other borrowed clocks is still allowed thanks to the impl<T: Clock + ?Sized> Clock for &T {}.

This is of course a breaking change.

[Matthias247]

Hi. Sorrry for the late response first of all.

I'm aware about the drawbacks of dynamic dispatch here. But static dispatch also has it's issues of having to thread a generic type through all layers of code. I had hoped to use the amount of generics in this library, since currently using it - instead of tokio primitives - creates a lot more type noise and probably also worse compilation times.

This change would however go into the opposite direction. And now require some piece of code which earlier on didn't have to care about the timer type (same was e.g. when using tokio::time::sleep) now needing to be aware about it.

Therefore, and due to changing the API, I'm currently not super inclined to go forward with this.
If there are however some more people who could describe their concrete use-cases for this, and the timer in general, I would be open to changing it in a future version. I can leave the CR around for this.