[Untested] Add Initial Hydra Config

[Jack-Khuu]

We currently use argparsers, but as we land more features, this will grow unwieldy and we'll want a unified config for controlling all the individual agent components.

This PR adds an initial Hydra setup and migrates all existing clis to leverage hydra yamls.
The original behavior/args for each of the CLI's is unchanged by this PR

We also introduces a tests/commands.md which will be used to sanity check the changes, but can be repurposed for documentation and actual testing suites

---

Note 1: Hydra configs are typically nested to mirror hierarchical modularity. We choose NOT to do so as an intentional design decision for rapid prototyping (i.e. unified yaml, see auto_agent.yaml)

Note 2: This PR does not change which/how the arguments are consumed. These changes will be made separately
(e.g. add missing/useful fields, tweak inconsistent defaults, wire hardcoded or unused args, etc)

Note 3: We can follow up this PR to use StructuredConfigs once the cli is a bit more stable

---

Testing

TODO: See tests/commands.md

[Laurawly]

High-level, I’m good on using Hydra as long as we keep it as a thin CLI/config layer on top of the existing dataclasses. In other words:

Core library code (Fuser internals, triton_kernel_agent) should stay Hydra-free and continue to use our existing config/dataclasses and plain Python types.

The Hydra DictConfig should be converted into those dataclasses at the CLI boundary (e.g. in auto_agent.py / cli.py), rather than passed deeper into the system.

We should preserve the current user-facing UX (python -m Fuser.auto_agent --problem ... etc.) and treat Hydra/yaml as an ergonomics win, not something users must learn to run basic workflows.

Be extra careful with path handling and Hydra’s working-directory behavior so we don’t accidentally break .fuse paths or relative problem paths.

If we can keep those boundaries in place, I think Hydra is a nice incremental improvement rather than a risky rewrite.