Add support for operation-level sample rates

## Feature Request

Some systems have a mix of high volume and low volume operations. Sampling low volume operations can be problematic since they may be missed (depending on actual volume and sample rate), leading to lack of visibility. If the same system also has very high volume operations, the Hive usage quota can be exhausted by the high volume operations and require paying for 100% of operations when sampling those operations would be sufficient.

Global sampling forces the user to decide between overpaying for operation quota or risking lack of visibility for low volume operations. The ability to specify sample rates on an operation level would enable sampling the known high volume operations while tracking 100% of low volume operations.

## Design Idea (for Apollo Router)

Support a new config block named `operation_sample_rates` which contains a list of config objects. Config objects could contain operation names to be matched exactly or regular expression patterns (in the same spirit as #3493).

```
supergraph:
listen: 0.0.0.0:4000
plugins:
hive.usage:
{}
# Default: true
# enabled: true
#
# Sample rate to determine sampling.
# 0.0 = 0% chance of being sent
# 1.0 = 100% chance of being sent.
# Default: 1.0
# sample_rate: "0.5",
#
# Operation-level sample rates.
# Default: []
# operation_sample_rates:
# - name: SampledQuery
# sample_rate: 0.1
# - regex: /^Sampled.*/
# sample_rate: 0.1
#
# A list of operations (by name) to be ignored by Hive.
# exclude: ["IntrospectionQuery", "MeQuery"],
```

## Considerations
- When a global sample rate and an operation sample rate are defined, which should take priority?
- It seems like the operation sample rate should take priority
- Or, the system could take the min or max of both values