WIP: RoutingBlobAccess

[minor-fixes]

This change adds a config option for RoutingBlobAccess, which is intended to hold all possible ways to rewrite instance names.

While it is possible to affect instance name by (ab)using DemultiplexingBlobAccess, there are some sharp edges (e.g. using it to add an instance name may not work as expected, as not only must the instance name be valid on the inner blobstore, but it must be valid once returned upwards as well). RoutingBlobAccess will attempt to fix that by offering easier-to-use semantics around instance name rewriting.

Tested: builds only, never ran

---

This PR's current purpose is to:

• give me an opportunity to familiarize myself with the codebase (OK if this is a bad idea and should die here - I learned things)
• validate the proposal of adding a BlobAccess wrapper with these semantics (vs. e.g. bug fixes to DemultiplexingBlobAccess)
  • I still need to go back and collect specific details/minimal repro for issues found using instance renaming with DemultiplexingBlobAccess, to better make the case for this
• shed light on any misguided assumptions I have about how digests/instance names propagate through various backends

[EdSchouten]

using it to add an instance name may not work as expected, as not only must the instance name be valid on the inner blobstore, but it must be valid once returned upwards as well

This I don't understand. Are you saying that this currently does not hold? Namely, that BlobAccess.FindMissing() returns digests that can't be translated back to the original instance name? If that's the case, then we should figure out why that is happening.