Introduce ConfigBuilder as an alternative to our existing Config constructors.

I noticed that the existing constructors, Config::load_with_cli_overrides() and Config::load_with_cli_overrides_and_harness_overrides(), did not take codex_home as a parameter, which can be a problem.

Historically, when Codex was purely a CLI, we wanted to be extra sure that the creation of codex_home was always done via find_codex_home(), so we did not expose codex_home as a parameter when creating Config in business logic. But in integration tests, codex_home nearly always needs to be configured (as a temp directory), which is why callers would have to go through Config::load_from_base_config_with_overrides() instead.

Now that the Codex harness also functions as an app server, which could conceivably load multiple threads where codex_home is parameterized differently in each one, I think it makes sense to make this configurable. Going to a builder pattern makes it more flexible to ensure an arbitrary permutation of options can be set when constructing a Config while using the appropriate defaults for the options that aren't set explicitly.

Ultimately, I think this should make it possible for us to make Config::load_from_base_config_with_overrides() private because all integration tests should be able to leverage ConfigBuilder instead. Though there could be edge cases, so I'll pursue that migration after we get through the current config overhaul.

Stack created with Sapling. Best reviewed with ReviewStack.

• feat: migrate to new constraint-based loading strategy #8237
• -> fix: introduce ConfigBuilder #8235