Add --fabric.addMods / -Dfabric.addMods for adding extra path separator separated mods, list file if prefixed with @

[sfPlayer1]

This allows to specify extra mods with

• the --fabric.addMods program argument
• the -Dfabric.addMods jvm argument

Each takes a path separated list similar to the class path, e.g. --fabric.addMods=path/modA.jar:/some/path/modB.jar on Linux/MacOS or --fabric.addMods=path/modA.jar;/some/path/modB.jaron Windows

Valid entries for this list are:

• mod jars
• unpackaged mod directories (as used in-dev)
• @-prefixed mod list files with one of the above in each line, similar to java/javac command line argument files

A mod list reference like -Dfabric.addMods=@/some/modList.txt expects modList.txt to contain e.g.

path/modA.jar
/some/path/modB.jar

This PR touches argument handling to ensure correct behavior with Launchwrapper and move some MC specific code where it belongs.

resolves #282 - the launcher has to translate to plain paths though

[jordanamr]

Looks good to me :)

[Chocohead]

Why null out the arguments? Just because they're not needed anymore?

[liach]

maybe to allow garbage collection?

[sfPlayer1]

just to trap any accidental reuse

[vico93]

Thank you for this

[NatoBoram]

Little note for people coming from FabricMC/fabric-installer#53, #181, #357, #521, #512, FabricMC/fabric#1123, #671, #615:

if -Dfabric.addMods= points to a folder path it'll add that recursively
if you however want to have a mods folder for a specific mc version or mod pack you really should instead create a separate "installation" inside the launcher with a custom game directory
which will also isolate the configs and world saves beyond just the mods folder