Range and Metarange per StorageID

[nadavsteindler]

This came up during the tierfs issue #8546
The idea is to refactor ranges/metaranges to support a single StorageID

The changes here and in range_manager.go seem odd. AFAICT, a metarange from a storage backend will manage ranges from that same backend. So why not hold storage ID on the metarange and range managers? Everything on them is either externally owned (like TierFS) or reference-counted (like the pebble read cache, which we manage as "cache Unrefer"). So committedManager might hold a map from StorageID to their metarange and range managers. This would allow us to limit the spread of StorageIDs throughout the code.

Possible implementation: #8594

Tests for CommittedManager