[RFC][Config] Add torchtitan_configs for full training configurations (#4114)

[pianpwk]

Stack from ghstack (oldest at bottom):

• [pls don't review yet] Prototype spmd_types graph trainer SimpleFSDP #4160
• spmd_types as default backend #4085
• -> [RFC][Config] Add torchtitan_configs for full training configurations (#4114) #4176
• Add torch_checkpointing save config plumbing (#4058) #4175

Stack from ghstack
(oldest at bottom):

• -> [RFC][Config] Add torchtitan_configs for full training configurations #4114

TL;DR

We plan to remove most CLI options, especially the options related to
models, optimization, and parallelism, in the future. All users should
use configuration programming to create their own Trainer.Config,
which can be done easily with a coding agent. If CLI is a must, users
can create their own CLI on top of the configuration system.

Motivation

There are several problems with the current configuration + CLI system.
The two major ones developers hit today:

1. update_from_config: some configurations can only be decided after
   the CLI is parsed, so every model has to provide an update_from_config
   to update the model configurations (e.g., sharding, optimization,
   backends) from the "new" configurations coming out of the CLI. This path
   is indirect and painful to maintain.

2. CLI option exposure: when developers add a new feature they have to
   think about whether and how to expose the option, because the CLI is the
   entry to expose a knob. This is further amplified by the first issue --
   developers also need to understand how (or if) update_from_config
   interacts with the new knob.

Implementation

torchtitan_configs is a package that lives outside the core torchtitan
folder and is installed by pip install. It is not going to contain all
use cases, because there are exponentially many combinations. It will
only contains the test configs and some golden configs we verify on
certain hardware. Users can put their own configs in this folder to
launch a job.

Tentative Plan

1. Introduce the torchtitan_configs package and freeze the CLI (this
   PR): Users should launch with MODULE=torchtitan_configs.tests CONFIG=llama3_debugmodel_fsdp2_cp2 ./run_train.sh and no further CLI
   options. Replace "tests" and "llama3_debugmodel_fsdp2_cp2" to fit your
   setting. To change options, change the configuration instead of
   appending a CLI flag. The existing flags still work, but only for
   backward compatibility; they are no longer the recommended way to
   configure a run.

2. Move all the integration tests to use the new way to launch jobs.

3. Demonstrate and document how to replace a module: With the future
   removal of the CLI, using a different implementation/optimization is
   done through config replacement. This step will document and demonstrate
   how to achieve that. [CP] Pluggable CP attention via cp_method + attention_sharding #3978 is
   the tentative PR (still WIP).

4. Optimization composability: Now that optimizations are composed by
   replacing configs, we need to make sure these optimizations still
   compose. This needs more discussion and thought on the composability,
   and on whether there is a composability issue at all. We also need to
   understand if input_dst_sharding is still required.

5. Split update_from_config: It does three different things:
   validation, derivation of the sharding configs, and the RoPE cache
   resize. Move the validation to one place so that every model does not
   need to implement its own, and leave the RoPE resize where it is. This
   step does not change any CLI behavior.

6. Move the derivation into the configuration functions, which removes
   the rest of update_from_config: The derivation reads
   --parallelism.enable_sequence_parallel and
   --parallelism.expert_parallel_degree, and the CLI can still change
   them after the configuration function has run, so these two options have
   to go first. This is why steps 5 and 6 come late: users need time to
   move off these flags, and step 2 already removes the integration tests'
   dependency on them. This is also a BC breaking step, both for the two
   flags and for any out-of-repo model that implements its own
   update_from_config.

7. Restructure configurations and trim CLI options and leave only the
   necessary ones: This is a huge BC breaking step. Tentative proposal,
   very early version, read this only if you are interested,
   https://gist.github.com/fegin/276f0b6d3d7a80ae2573516b25917166