[refactor] Move configuration files to single YAML file

[ervteng]

Proposed change(s)

This PR refactors the YAML configuration files into a per-environment format. Each YAML now contains both the behavior configurations/hyperparameters, as well as curriculum and parameter variation configurations. The example YAMLs were reformatted to reflect this.

To be done in this PR:

• Documentation changes

Not done in this PR:

• Move engine configurations and other CLI options (num_envs, env, seed) into YAML files as well
• Save out final YAML file.

Useful links (Github issues, JIRA tickets, ML-Agents forum threads etc.)

https://docs.google.com/document/d/1uyk5JVNevfWy2DmqVHy19lcDzyQCNppPxkPOgJcQ7z4/edit#heading=h.sozm3sblhtke

Types of change(s)

• Bug fix
• New feature
• Code refactor
• Breaking change
• Documentation update
• Other (please describe)

Checklist

• Added tests that prove my fix is effective or that my feature works
• Updated the changelog (if applicable)
• Updated the documentation (if applicable)
• Updated the migration guide (if applicable)

Other comments

[ervteng]

@anupambhatnagar - this will definitely break daily CI - what steps should I take to adapt the ml-agents-cloud utility to match?

[awjuliani]

How did you generate all of these files. I worry now about keeping track of changing defaults. I know that moving the defaults into code is out of the scope, but I just want to make sure we aren't signing up for the extra work that might be associated with managing multiple dozen config files now.

I also remember us talking about separating the YAML behavior section into a trainer and model sub-sections. Is that out of scope as well, or has the plan changed? I think it would definitely improve interpretability.

[ervteng]

@awjuliani I still want to split the YAML to trainer and model. With luck that will be done after the other CLI and output file changes are done.

The files were generated using a script that loaded the old config's default and overrode them using the config, then outputted the new YAML. I'm also worried about the files diverging before we are able to create the default values in code. This PR is technically still compatible with the old config files (as long as you add behaviors:) to it.

Would it be a good idea to have an intermediary step that uses the old trainer_config and only migrates generalization/curriculum? We can then migrate the others when the defaults are properly codified.

[anupam-142857]

looks good. I recommend running it on one scene with ml-agents-cloud to test the new workflow.