We have, essentially, four classes of ServerStatusSection today -

• those that are router-only and should only be included in the router-role server-status output;
• those that are shard-only and should only be included in the shard-role server-status output;
• those that contain information about the process or hardware rather than the role, and should be included in the output for both shards and routers
• those that exist in both roles, but potentially have different content under the same name

Today, we support the first case by tagging the section-builder with `.forRouter()`, the second with `.forShard()`, the third by registering a single instance of the section with `.forShard().forRouter()`, and the fourth by registering two different instances with the builder, one with `.forShard()` and one with `.forRouter()`

It may be worth making tagging-functions aware of the classes we're partioning the sections into, to remove any ambiguity between the third and fourth classes with the pattern for registration we use today. So we could simply have helpers for role-aware metrics that will register a separate instance for each role they should work with, and another for non-role-aware metrics (the third case above).

It may be worth doing this after SERVER-87870 is complete.