Core config: Defer Deserialization

[nattthebear]

Config file storage of core settings and sync settings would not be in an object whose type was eagerly resolved and deserialized at application start, but rather a JObject with actual deserializer binding to be done later.

Benefits:

• A core settings change/incompatibility doesn't crash whole config deserialization, making the user replace the everything; instead, these breakages are contained within the single core's settings.
• We don't have to hit the type load and initialize for 30458304534 emulator types on initial hawk startup. That's a lot of classloader and a lot of jit time, maybe.
  • Most definitely affects start-up time—see also #1811
  • For instance, a static initializer for quicknes settings calls into unmanaged code, hich means that to load our config, we go all the way through class load for bizinvoker, and bizinvoke generation stubs for the libquicknes, and then native loadlib of quicknes...

This change would help ease some of the issues in https://github.com/TASVideos/BizHawk/issues/2094 but not entirely fix it

[YoshiRulz]

Tried moving BizInvoker usage from QuickNES static ctor to static lazy, but it's not being hit by loading shenanigans for the QuickNES type, it's being genuinely hit by QuickNESSettings.SetDefaultColors (called from QuickNESSettings ctor). That overhead isn't going anywhere until we change deserialisation.

[nattthebear]

I think trying to clean up the static initializers will be whack a mole; a general solution with the serializer is more scaleable

[nattthebear]

2f18ad5