Find tradeoff for number of goroutines during Gather

[beorn7]

https://github.com/prometheus/client_golang/blob/master/prometheus/registry.go#L381 starts one goroutine per registered Collector. Cases of 1M registered collectors have been reported. With fast collections, the overhead of starting a goroutine isn't really worth it, and there is a notable memory peak caused by it. Let's come up with a way to adaptively find a tradeoff. With fast collectors, one goroutine is fine. Even with slow ones, starting thousands of goroutine will have diminishing returns.

[brian-brazil]

I'd try using only one goroutine for the standard gauge/counter/summary/histogram metrics.

[beorn7]

Then we needed to treat Collectors differently depending on their implementation. It would make the abstraction leaky.