Triage and break up the global settings

[Ericson2314]

Thinking through #5603, and the two getDefaultSystemFeatures reminded me of this:

1. We have many global settings that should be per-store. thisSytem and extraPlatforms are good examples. This works best after Split Store class #5729 so that we don't pollute stores like HttpBinaryCacheStore with these new per-store options that don't make sense for them.

2. We have too much ad-hoc logic around build remotes that should be fixed up to use per-store settings instead, as we did before with system features in 4720853

   • We should probably make stores that can build a subclass of stores that just are read/written. Then we don't have to do silly things like say what "extraPlatforms" s3://... has.

3. Separate stores for evaluation, building and storing the result #5025 (comment) remains a very good idea. Then many of the remaining settings which aren't per-store would make sense as an additional config parameter to this now-freestanding (not Store method) function.

4. Finally, there may be global settings that are for the libstore layer at all, and they can be moved to another downstream library.

[rickynils]

I'm dumping some references here, where discussions about options propagation to remote builders can be found:

#5600
#2994
#4180

The issue is that when using remote builders or remote stores, it is not at all clear what options will be in effect. For ssh:// there is a small set of settings propagated, for ssh-ng:// almost no options (I think builders-use-substitutes is the only one) are propagated. It doesn't make sense to propagate all Nix options indiscriminately, because many settings are related to aspects of the local machine. If I understand this issue correctly, we could identify options that are related to specific types of stores and then propagate these when such remote stores are used?