feat: support in-repo .codex/config.toml entries as sources of config info (#8354)

- We now support `.codex/config.toml` in repo (from `cwd` up to the
first `.git` found, if any) as layers in `ConfigLayerStack`. A new
`ConfigLayerSource::Project` variant was added to support this.
- In doing this work, I realized that we were resolving relative paths
in `config.toml` after merging everything into one `toml::Value`, which
is wrong: paths should be relativized with respect to the folder
containing the `config.toml` that was deserialized. This PR introduces a
deserialize/re-serialize strategy to account for this in
`resolve_config_paths()`. (This is why `Serialize` is added to so many
types as part of this PR.)
- Added tests to verify this new behavior.



---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8354).
* #8359
* __->__ #8354

codex-rs/utils/absolute-path/src/lib.rs

@@ -14,7 +14,7 @@ use ts_rs::TS;
 /// guaranteed to be canonicalized or exist on the filesystem).
 ///
 /// IMPORTANT: When deserializing an `AbsolutePathBuf`, a base path must be set
-/// using `AbsolutePathBufGuard::new(base_path)`. If no base path is set, the
+/// using [AbsolutePathBufGuard::new]. If no base path is set, the
 /// deserialization will fail unless the path being deserialized is already
 /// absolute.
 #[derive(Debug, Clone, PartialEq, Eq, Serialize, JsonSchema, TS)]
@@ -112,6 +112,10 @@ thread_local! {
     static ABSOLUTE_PATH_BASE: RefCell<Option<PathBuf>> = const { RefCell::new(None) };
 }
 
+/// Ensure this guard is held while deserializing `AbsolutePathBuf` values to
+/// provide a base path for resolving relative paths. Because this relies on
+/// thread-local storage, the deserialization must be single-threaded and
+/// occur on the same thread that created the guard.
 pub struct AbsolutePathBufGuard;
 
 impl AbsolutePathBufGuard {