Refactor Metrics API to use Services again, make global MetricsChannel optional

[atooni]

Based on the discussion on discord between swachter / atooni, in order to align open PR's:

1. We would have a metrics service agian, which would expose a unified (backend independent) API for capturing metrics. This would be more or less along the methods that I have moved into the new ZMX package object.
   [11:29 AM]
2. That service can be vertically composed with another Service (in my terms an Instrumentation) which would be responsible for mapping the captured data to a backend specific data model and send it to the backend.
   [11:30 AM]
3. We would prefer the usage of the Metrics Service using Layers, thereby eliminating the requirement for specific shutdown hooks
   [11:31 AM]
4. For convenience we could provide lazy vals (one for statsd and one for prometheus) which could be used instead of the layer based approach, so that users have the choice what they want to use for instrumentation.
   [11:34 AM]
5. We would keep the separation of the datamodels : ZMX / Statsd / Prometheus. Before the datamodel was more or less coupled to StatsD, which was a bit inconvenient for mapping it to Prometheus.
   [11:36 AM]
   If my understanding is correct, I am happy to create a ticket along these lines and work on that as my time allows. As soon as the ticket is opened I would also create a draft PR to share and discuss early. I would also like to pull @adamfraser into the loop as he was my main contact for reviews.

[adamgfraser]

Closed by #209.