Add patch for broken SteamVR focus handling

[goaaats]

This fixes an issue wherein the resolution scale for SteamVR cameras could become permanently stuck on 0.5f due to broken logic in SteamVR.

I wasn't sure if this really fits into "Resonite Monkeys" but it causes headaches in Resonite since it does tend to hitch a lot, which causes the bug to reproduce, and there isn't a better spot from what I can tell apart from making a separate mod.

This happens because the SteamVR Unity plugin can sometimes miss events when the game is hitching.
The resolution is set to 0.5f in SteamVR_Render.OnInputFocus() as a response to the unfocus event, but when the unfocus event happens twice in a row - as a result of a dropped refocus event - the code stores the already reduced resolution as the current resolution, causing it to never go back to the original resolution once a focus event occurs.
This is ostensibly a bug in the SteamVR plugin, but it would be trivially fixed by tracking the focus state in SteamVR_Render and not storing the overridden resolution in the field for the actual resolution. The lost events are somewhat troubling but the code that gets events from the OpenVR native looks fine to me, and it seems like this is just expected behavior from OpenVR if your app is unresponsive for multiple seconds.

Yellow-Dog-Man/Resonite-Issues#2337

[Banane9]

I also think making it disablable would be fine, just to keep it the same as all the other ones - though that would only concern the not updating the resolution part 🤔

You can use a ResoniteBugFixMonkey as the base, too

[Nytra]

this patches Unity stuff so it will break after splittening

[Banane9]

this patches Unity stuff so it will break after splittening

Yea, will have to see how we deal with that when the pre-release comes out - and it'll still be needed then, since there'll still be Unity for rendering

[goaaats]

Fixed the things that came up, I'll leave it up to you to decide whether you want to merge this so close to the split, I fully understand if you'd rather hold off for now.

This might not even be a real issue anymore afterwards, depending on how the Unity renderer is implemented. If it doesn't lock the main thread while waiting for data from the engine I assume it would be very rare for someone to run into this :)

[Banane9]

Fixed the things that came up, I'll leave it up to you to decide whether you want to merge this so close to the split, I fully understand if you'd rather hold off for now.

It doesn't directly reference any types, so nothing else will break even if the process it's loaded in doesn't have Unity, so it's all good :D

---

This might not even be a real issue anymore afterwards, depending on how the Unity renderer is implemented. If it doesn't lock the main thread while waiting for data from the engine I assume it would be very rare for someone to run into this :)

Still something that could feasibly happen, so it doesn't hurt to have it fixed imo