feat: Make usage of patch names case insensitive

[LisoUseInAIKyrios]

Feature description

It's difficult enough for new users and non technically people to figure out CLI, and when using CLI the user should not be expected to double check the letter casing of a patch name they want to include/exclude.

Referring to a patch by name should allow using any casing:
GmsCore support, GmsCore Support, gmscore support, etc.

This issue may need to move to patcher repo instead of CLI.

Motivation

Stop senseless torturing users with unnecessary complexity that provides no benefit.

Acknowledgements

• I have checked all open and closed feature requests and this is not a duplicate.
• I have chosen an appropriate title.

[wchill]

Why not just require a config file for the CLI and get rid of the command line arguments altogether?

• I was thinking about adding a "generate config file" command that would allow for dumping a sample patch config via JSON. This would help with incorrect patch casing since users can just use the generated config as a template and toggle patches on/off by flipping a flag in that config file.
• We need the config file functionality anyway for automated testing, unless we want to write logic to generate all the command line arguments needed.
• Trying to toggle patches on/off and set options via command line has always been painful, because you need to run the CLI at least once to know what the patch names and option keys are. It's way easier to update a file.
• The existing logic for trying to parse arrays, floats, etc from strings works, but it makes more sense from a maintainability perspective to use standard serialization libraries that are capable of handling all of this already.
• Users can ideally reuse their patch configs between manager and CLI.

[wchill]

Related: #23 talks about indexes, but indexes are kind of bad given their instability based on which patch bundles are loaded. Distinguishing between several patches with the same name should be done via namespacing, which would be much easier to do in a config file.

[LisoUseInAIKyrios]

I had nothing to do with the referencing patches by index design decisions or implementations, but I think it may work relative to the last patches argument (syntax may not be exactly correct here, can't check away from computer): --patches foo.mpp -d 1 --patches bar.mpp -d 1 // disable first patch of each bundle. Not sure on this need to check.

Previously the patch options were a JSON file. It required generating then editing it. It was a lot easier to edit but it also turned into a hassle when patch options were added/changed because the json is then outdated so then it's an issue of migrating the json. Command arguments don't have that issue and don't require generating anything. If JSON option input is added, I think the existing arguments should be kept for backwards compatibility (or at least an attempt is made to keep backwards compatibility).

[wchill]

Regarding the indexing, the CLI help mentions Index of the patch in the combined list of the supplied MPP files. so I believe it's an index into the combined list, not per bundle.

Wouldn't you have the same issue with command arguments when options are added/changed? I don't particularly see the JSON migration as an issue assuming the CLI is capable of the following workflow:

1. User generates template with CLI and modifies patch options.
2. Patches are updated.
3. User attempts to use updated patches with old config.
4. CLI loads old config, notices that the options do not match up with user provided config, errors out, and either automatically generates a new config (with all user options copied over except the ones that changed) or offers to do so for the user.
5. User edits the newly generated config, updates patch options, and attempts patching again.

That being said, I did attempt to prototype an implementation of this while keeping backwards compatibility. It is doable, but there are some headaches. I'm thinking of changing the CLI logic to convert the command line arguments into JSON serializable types as an intermediate step instead of directly to the current Map<String, Any?> that they're being converted into right now.

[LisoUseInAIKyrios]

When options are renamed then CLI argument usage has to be renamed too.

But when new arguments are added, it requires manually adding the json and the option data unless the json template is regenerated and manually move the old json options over. I find this more of a hassle than simple adding -Owhatever=false. But, if CLI can do step 4 you described and migrate (update) the input options and save it to disk, then that would be an improvement because right now any large practical CLI usage requires storing the arguments in a text file and xarg'ing it into the CLI command (or hard coding into a script file).

If it's done how you describe I think it will be an improvement. If it's not difficult to support the old CLI arguments (write out a temporary JSON as you suggested) it would have no time cost for anyone to change their existing ways unless they wanted to