Blocking detector with event volume throttling

[jamescrosswell]

This is a variant of:

• feat: blocking detection #2709

In the other PR (that we want to merge) we removed some code that had been added to address volume concerns.

The original thinking was that if blocking calls exist on a hot path, we don't want to be sending thousands of events that all communicate the same thing. This PR includes a mechanism to record when each blocking call was last reported to Sentry and skip reporting if we detect the same blocking call within a cooldown period (hard coded to 1 day).

In this PR the blocking detector also emits a System.Diagnostics.Metric each time a blocking call is detected, using the code location as a tag, so that people can known how often a particular blocking call occurs.

There were concerns about emitting internal metrics when our Metrics product is so naiscent however... and also about the UX experience, which with this implementation would look something like this:

A location tag is added to the blocking call metrics and whilst it would be possible to add this same tag to the blocking call events and use that as a correlation id, there's no "standard" established for doing that across the other Sentry APIs yet (discussions about that haven't happened).

This PR exists mainly to preserve the solution we came up with in case we want to revisit or ressurect it once wider discussions across Sentry are a bit more mature.

[github-actions]

	Fails
🚫	Please consider adding a changelog entry for the next release.

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

- Blocking detector with event volume throttling ([#3174](https://github.com/getsentry/sentry-dotnet/pull/3174))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description.

Generated by 🚫 dangerJS against 39926f4