Currently, `ShardingTestFixture` isn't able to become aware of the `ClusterRole`s that are assigned to it. By default, it is assigned only `ClusterRole::ShardServer`. In some cases, however, a particular test fixture will inherit from `RouterRoleOverride`, which assigns `ClusterRole::RouterServer` and then from `ShardingTestFixture`. At the time of writing, the following fixtures follow this pattern:

• `BatchWriteExecTest`
• `TransactionRouterTest`

In these cases, only `ClusterRole::RouterServer` is set. As a result, it's difficult to make a judgment call for which `Service` to assign the `CatalogCacheLoader` to in the `ShardingTestFixture` constructor, and more generally, it's difficult to reason about what `ClusterRole`s a `ShardingTestFixture` might be assigned (or any subclass of `ServiceContextTest` for that matter).

Add support for discovering the `ClusterRole`s that are set for tests that inherit from `ServiceContextTest` and the role override classes. Implementation will likely require reinstrumenting the way that the role override classes are inherited from (george.wangensteen@mongodb.com has suggested using CRTP). Once support is in place, remove the TODO in `ShardingTestFixture` and explicitly discover the correct `ClusterRole` to associate the `CatalogCacheLoader` with.