WIP get rid of global `Settings` in libstore

[Ericson2314]

Motivation

Big progress on #5603

Context

This is analogous to 52bfccf8d8112ba738e6fc9e4891f85b6b864566 for EvalSettings, and 3fc77f281ef3def1f997c959687cba04660dd27d for FlakeSettings and fetchers::Settings.

---

Add :+1: to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[edolstra]

C++ isn't Haskell. It's fine to use global variables for global settings. Passing down settings objects everywhere is very annoying.

[Ericson2314]

So the intent is that the next step would be able to write a bunch more structs, breaking up Settings into the relevant options that individual components need,

That would in turn inform us about:

1. How new JSON settings should be structured hierarchically. We don't want to continue overwhelming the user with a giant flat unstructured namespace of settings
2. What CLI command should get what flags. We don't want to continue spamming CLI commands with tons of irrelevant flags.

[edolstra]

So the intent is that the next step would be able to write a bunch more structs, breaking up Settings into the relevant options that individual components need,

That makes it worse. I really don't want to pass a dozen of Settings objects around to function at the top of the call stack...

How new JSON settings should be structured hierarchically. We don't want to continue overwhelming the user with a giant flat unstructured namespace of settings

That can be done without this (e.g. by allowing dots in the setting name), and in any case it's unclear how much utility this has in practice.

What CLI command should get what flags. We don't want to continue spamming CLI commands with tons of irrelevant flags.

Settings are already excluded from tab completion for --, and they're not shown in the man pages.

So the only change would be that --<setting> will fail if a setting does not apply to a command, but I'm not even sure how desirable that is for global settings.