Add "Platform" modes, isolate tools based on target

[flibitijibibo]

A big problem I'm having with XnaToFna's out-of-the-box experience at the moment is that it's doing a LOT of work that it doesn't necessarily need to; this commit gets what I've found so far...

678f847

... but now that we have Proton on the table, it may be worth reconsidering the UX to act in three modes:

• Windows Mode: Default. Just relink, re-encode WMA/WMV, and fix up Forms usage.
• Linux Mode: Same as Windows Mode, but with case sensitivity fixes
• 360 Mode: Same as Windows Mode, but ignores Forms relinking and fixes endianness

All other options should be disabled and only enabled upon request when doing research-y things (stuff like force-anycpu, for example).

The idea is that we can potentially make it so Proton XNA games can just pull in an XnaToFna-Proton zip that includes XnaToFna, FNA 18.10, and fnalibs Windows x86, run in Windows Mode, then the game can execute under wine-mono without having to worry about the C++/CLI compat issues.

[0x0ade]

In my opinion, "Windows mode" should be the default, containing a set of "sensible" defaults (f.e. fixing Forms). And to some extent, it already is, but I need to minimize the set of options enabled by default (f.e. fixing P/Invoke, BinaryFormatter, reflection).

"Linux mode" wouldn't enable case-sensitivity fixes, but rather options such as the P/Invoke fixes.

Path case-sensitivity is entirely opt-in on a per-method basis, as it's only required when MONO_IOMAP isn't enough (i.e. when passing a path to a native library).

"X360 Mode" is an entirely beast altogether. It currently contains more GamerServices-, Net- and XDK-related stubs than I can count on my hand.

I'll get to working on slimming down the default enabled options.

[0x0ade]

Switched to using Mono.Options to parse the command line arguments. XnaToFna now accepts a --profile parameter:

XnaToFna/src/Program.cs

Lines 29 to 61 in 1b83dc7

	{ "profile=", "Choose between multiple base profiles:\ndefault, minimal, forms", v => {
	switch (v.ToLowerInvariant()) {
	case "default":
	xtf.HookCompat = true;
	xtf.HookHacks = true;
	xtf.HookEntryPoint = false;
	xtf.HookLocks = false;
	xtf.FixOldMonoXML = false;
	xtf.HookBinaryFormatter = true;
	xtf.HookReflection = true;
	break;
	case "minimal":
	xtf.HookCompat = false;
	xtf.HookHacks = false;
	xtf.HookEntryPoint = false;
	xtf.HookLocks = false;
	xtf.FixOldMonoXML = false;
	xtf.HookBinaryFormatter = false;
	xtf.HookReflection = false;
	break;
	case "forms":
	xtf.HookCompat = true;
	xtf.HookHacks = false;
	xtf.HookEntryPoint = true;
	xtf.HookLocks = false;
	xtf.FixOldMonoXML = false;
	xtf.HookBinaryFormatter = false;
	xtf.HookReflection = false;
	break;
	}
	} },

"Windows", "Linux" and "360" should map to forms, forms and minimal.
default enables a few defaults which I personally deem "sane" to be enabled out of the box for quick hackports, f.e. fixing BinaryFormatter and reflection.

All other features can be enabled or disabled manually. For a completely barebones experience, you could use --profile=minimal --relinkonly=true FNA.dll Game.exe

Is this good enough?

[flibitijibibo]

I'll try this out on Monday or Tuesday - my main concern is just making it easy enough to use for Proton, which usually means "no extras, no parameters, no nothing" as a really hard rule. If it works for our known catalog, this should be good.