This PR builds on open-telemetry#43201 (pending) to parallelize the decision ticker.
It also fixes the open issue in open-telemetry#41656 by moving all state management to
a single goroutine (per shard).

In practice at Grafana Labs, we've seen that the single threaded nature
of the decision ticker is the primary bottleneck when running the tail
sampling processor at high scales. For example, we have one large
cluster performing around 12M policy evaluations per second while
maintaining p99 tick latency of around 500ms. In order to reach this
scale, we need to run ~200 replicas just to get enough parallel threads
of execution. By adding support for parallel decision ticks, we hope to
run fewer, larger replicas which should reduce the fragmentation
caused by trace id load balancing.

Another benefit here is to reduce contention on the idToTrace map and generally
simplify reasoning about concurrency by giving each trace a clear
"owner" goroutine. Previously we'd try to do some work inside the calling
goroutine of ConsumeTraces. Instead, new work is passed via channels to
its dedicated shard. By default we run one shard per available core.
Shared state is kept to the minimum required to implement TSP semantics:

1. The trace limiter is shared, which allows the overall memory
   consumption to be reliably capped even in case of uneven shard
   utilization.
2. Both decision caches are shared, which again allows overall memory
   consumption to be capped even with uneven shard utilization.

In practice, shard utilization should be very even, but it's still nice
to have hard guarantees on the total traces in memory, and this allows
us to avoid changing any tests in this PR, which greatly increases my
confidence in the code despite the large change. Ideally the change to
parallel execution is invisible to end users (aside from the much higher throughput).

Sharding makes use of the maphash package with a unique `Seed`, which
should provide even shard distribution even if traceIDs have previously
been sampled downstream. This is better than e.g. a simple modulo on
traceID, since traceIDs are not necessarily uniformly distribute after
head sampling.

This PR builds on open-telemetry#43201 (pending) to parallelize the decision ticker.
It also fixes the open issue in open-telemetry#41656 by moving all state management to
a single goroutine (per shard).

In practice at Grafana Labs, we've seen that the single threaded nature
of the decision ticker is the primary bottleneck when running the tail
sampling processor at high scales. For example, we have one large
cluster performing around 12M policy evaluations per second while
maintaining p99 tick latency of around 500ms. In order to reach this
scale, we need to run ~200 replicas just to get enough parallel threads
of execution. By adding support for parallel decision ticks, we hope to
run fewer, larger replicas which should reduce the fragmentation
caused by trace id load balancing.

Another benefit here is to reduce contention on the idToTrace map and generally
simplify reasoning about concurrency by giving each trace a clear
"owner" goroutine. Previously we'd try to do some work inside the calling
goroutine of ConsumeTraces. Instead, new work is passed via channels to
its dedicated shard. By default we run one shard per available core.
Shared state is kept to the minimum required to implement TSP semantics:

1. The trace limiter is shared, which allows the overall memory
   consumption to be reliably capped even in case of uneven shard
   utilization.
2. Both decision caches are shared, which again allows overall memory
   consumption to be capped even with uneven shard utilization.

In practice, shard utilization should be very even, but it's still nice
to have hard guarantees on the total traces in memory, and this allows
us to avoid changing any tests in this PR, which greatly increases my
confidence in the code despite the large change. Ideally the change to
parallel execution is invisible to end users (aside from the much higher throughput).

Sharding makes use of the maphash package with a unique `Seed`, which
should provide even shard distribution even if traceIDs have previously
been sampled downstream. This is better than e.g. a simple modulo on
traceID, since traceIDs are not necessarily uniformly distribute after
head sampling.