ring: add GetWithOptions method to adjust per call behavior

[56quarters]

What this PR does:

This change adds a new method that accepts 0 or more Option instances that modify the behavior of the call. These options can (currently) be used to adjust the replication factor for a particular key or use buffers to avoid excessive allocation.

Which issue(s) this PR fixes:

Part of grafana/mimir#9944

Checklist

• Tests updated
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[56quarters]

I wasn't able to avoid the option functions escaping to the heap. Benchmarking the two methods shows that GetWithOptions is about 14% slower. I'm going to leave these as mostly separate methods and work on adding tests to GetWithOptions. After that I'll mark this as ready for review and we can start experimenting with higher replication factors in Mimir.

$ benchstat old.txt new.txt 
goos: linux
goarch: amd64
pkg: github.com/grafana/dskit/ring
cpu: Intel(R) Core(TM) i9-10885H CPU @ 2.40GHz
                                                         │   old.txt    │                new.txt                 │
                                                         │    sec/op    │    sec/op      vs base                 │
Ring_Get/without_zone_awareness-16                         863.2n ± ∞ ¹   1009.0n ± ∞ ¹        ~ (p=1.000 n=1) ²
Ring_Get/without_zone_awareness,_not_enough_instances-16   654.2n ± ∞ ¹    758.2n ± ∞ ¹        ~ (p=1.000 n=1) ²
Ring_Get/with_zone_awareness-16                            1.138µ ± ∞ ¹    1.252µ ± ∞ ¹        ~ (p=1.000 n=1) ²
Ring_Get/one_excluded_zone-16                              855.0n ± ∞ ¹    962.0n ± ∞ ¹        ~ (p=1.000 n=1) ²
geomean                                                    861.0n          979.7n        +13.80%

[56quarters]

After adding unit tests for this change, it turns out to not be compatible with zone-awareness. There's an assumption in the ring that only a single instance per zone is returned during quorum checks. The result of this is that there are Ring.Get() calls that should fail when not enough zones are available that would now succeed since we return multiple instances per zone and the existing code only checks the number of instances, not zones.

[56quarters]

I'm going to close this PR. The changes to the ring required for grafana/mimir#9944 are more complicated than expected. I'll put the various concerns into a design doc for some discussion with the Mimir team and other database teams as well.