Drop YAML config support for mod profile

[vswarte]

We've just added TOML and made it the default in the match, however I feel like we should consider dropping YAML entirely. Atleast for the time being.

Randomizer mods, for example, might want to parse the mod profile to offer additional support for other mods.
I feel like in the end we want to move this use-case to a dedicated API somehow, but on the short term it means they will have to add YAML support to their parsing procedure etc,

I also personally feel that supporting both formats will result in noise on the troubleshooting as well.

To top it all off, adding it back should be a backwards compatible change. (Later down the line when we have better facilities for mod detection).

[vswarte]

After a quick talk we've decided to immediately head for the correct solution which comes down to us parsing the config and offering a stable API for mod discovery.

[garyttierney]

Note: the real problem we're trying to solve here is allowing downstream "Launcher" programs to generate a mod profile. TOML support is not very widespread in other ecosystems (notably .NET), and something like YAML or JSON is easier to interop with.