Defend against too many concurrent scrapes

[beorn7]

If the /metrics endpoint is scraped too often concurrently, too much resources are claimed and the monitored binary might OOM because of a rogue monitoring server...

Reducing the resource usage of an individual scrape (e.g. by streaming more and buffering less as we do currently) increases the number of scrapes that can be performed in parallel, but doesn't fundamentally solve the problem. Adding "one more test monitoring server" could still crash production binaries. The HTTP exposition needs to be configurable in terms of max scrapes in flight and scrape timeout.

[beorn7]

With the new HandlerOpts, we can add an option for that without a breaking change.