Feature proposal: Configurable config folder

[williambl]

The path to the mods folder is configurable with a system property. This is useful for modpack installers, which may wish to decouple the mods folder from the game directory, letting a player use the same game directory (therefore the same saves, resource packs, options.txt) but with different sets of mods. (For example, the Iris installer does this.)

The config directory, however, is coupled to the game directory. This limits the usefulness of configuring the mods folder - a modpack installer which wishes to separate mods but keep resource packs, saves etc. accessible by changing fabric.modsFolder is forced to also keep the config folder the same... but modpacks often supply their own configs, and it's not acceptable to overwrite user configs.

Since the correct practice is to access the config directory using FabricLoader#getConfigDir method, making the config directory configurable in the same way as the mods folder would 'just work', without requiring any mod-facing API change or any change on the part of mods.

Proposal

Therefore I propose to add a fabric.configFolder system property, analagous to fabric.modsFolder.

Further options

Of course, usually a modpack would only want to override configs for one or two mods, and leave the rest up to the user. In that case, perhaps it'd be desirable to, as a later addition, allow configuring it per-modid, for example with fabric.configFolder.<modid> system properties. This would, however, require making FabricLoader#getConfigDir mod-sensitive somehow...

Another potentially useful future change for similar use-cases would be 'config folder stacks', i.e. providing an ordered list of config folders. This would be paired with a new method in FabricLoader, something like Stream<Path> getConfigFileStack(Path pathFromConfigFolderRoot). Mods could then choose to handle multiple config folders offering 'conflicting' files however makes sense for them - merging them, taking only one, etc. That requires mods to opt-in, and complicates their config loading, for a fairly limited use-case, though.