Fix issues with static variables

[thearst3rd]

This fixes the issue where attempting to start a new game either through Speedrun mode, or by hitting "Start New Game", would throw an error and create a bogus save file. This also fixes another small issue where the "1.12" version was missing from a few places, such as the bottom right of the start screen (it just showed as "v"), and the debug log.

Starting a new game uses the static variable ForcedLevelName to decide which level to load. For whatever reason, the presence of the static patch_Fez method was causing all static variables in the Fez class to not be properly initialized. Not sure if that's a C# thing or a MonoMod thing ¯\_(ツ)_/¯ Regardless, to fix the issue we need those variables to be loaded as normal.

This pull request removes the static function and moves the code that was there into the Initialize function. This seems to work just fine, however I feel it is likely that you chose to put the code in that static function instead, so I don't know if this is the best solution. My other solution, which is even dumber, is to just manually set the relevant variables in that static function:

diff --git a/Patches/Fez.cs b/Patches/Fez.cs
index ce29f9d..27d32f8 100644
--- a/Patches/Fez.cs
+++ b/Patches/Fez.cs
@@ -21,6 +21,8 @@ namespace FezGame
                 IHatInstaller installer = (IHatInstaller)Activator.CreateInstance(type);
                 installer.Install();
             }
+            ForcedLevelName = "GOMEZ_HOUSE_2D";
+            Version = "1.12";
         }

         protected extern void orig_Initialize();

That also seems to work ok, but it's very rigid and potentially only works with the exact version of the game I tested this with (DRM free copy from humble bundle, I didn't try it on steam). Anyways, these are my proposed solutions, you probably know much better than me what is the best approach so I leave it up to you.

[Krzyhau]

Executing IHatInstallers as soon as possible is wanted behaviour - that's why it was originally located in static constructor. However, I didn't expect it to cause such weird things as not initializing static members of the class, so thank you for pointing out this issue. I fixed it in 6c61d18 by applying patch to the regular constructor instead, which shouldn't introduce any unwanted behaviour anymore.