Improve configuration/composition of Prometheus metric collection

As of now, our Prometheus collectors are hard-coded into their respective submodules. This makes it hard to make changes to the metrics we expose. In particular, I see two use cases where better configuration/composability would benefit users:

1. Some of the metrics we expose are very detailed and mostly useful for debugging and development purpose. Since there is a cost to each collected metric (in terms of storage, processing time, or $ spent on Cloud services), it would be helpful to be able to configure which (sets of) metrics we want to expose for scraping.
2. Extensions or plugins may want to expose additional metrics, see the WorkStealingMetricCollector as an example. For these, having an easy way to (un)register collectors would be great.

The first point seems to be related to the second one. If we had an easy way to (un)register collectors, we could have a variety of optional collectors that users could register if desired.

[crusaderky]

+1 from me. It would let us clean up a lot of secondary steps for collection, drop crick entirely, and remove ugly hacks like the local maximums that are wiped clean at every collection.

[crusaderky]

We need a proper deprecation/versioning system.

Do we have a sense for how widely used these metrics are?

Discussion here: https://github.com/dask/distributed/issues/7385