Use SDL_GetKeyboardState instead of event polling

[thatcosmonaut]

We got a report from the Celeste modding/speedrunning community that FNA was causing input latency on keyboard relative to XNA. FNA currently processes keyboard input by processing all keyboard events in PollEvents and setting the keys in an internal array. But according to the report, XNA actually gets a new state every time Keyboard.GetState is called, not just once per frame. This patch brings the behavior in line with XNA, and it should address latency by allowing input polling to occur closer to when input is actually processed by the game.

We got a report from the Celeste modding/speedrunning community that FNA was causing input latency on keyboard relative to XNA when an IME was installed. This patch gets the keyboard state directly all at once instead of iterating over keydown events. This might address some scenarios where the keydown event is intercepted by something. It should also be very slightly more efficient to not have to call keys.Contains on all keypresses.

[flibitijibibo]

Functionally this makes sense, so we can go into the polishing stage at this point.

[flibitijibibo]

Took care of the notes, as long as this works as intended this is ready to go.

[flibitijibibo]

May as well update this since it came up recently: We have reason to believe that XNA actually calls GetAsyncKeyState directly when GetState is called, and SDL doesn't expose a direct mapping to this (nor should it, woof). This may improve behavior but accurate behavior is likely impossible without insane levels of intervention in this specific class...

[madewokherd]

I needed something like this for Wine Mono because I found the scenario where we need input events that were blocked: https://gitlab.winehq.org/mono/wine-mono/-/merge_requests/43

Revolver360 Re:Actor has an input library called Nuclex.Input that afaict hooks all keyboard messages through winforms and prevents them from being delivered. But the game doesn't use that library for keyboard input, it just calls Keyboard.GetState().

[flibitijibibo]

One last thing: Does the issue go away if we move our existing keydown/keyup events to an event watch? It's probably the best way to get these events without intercepting WndProc directly.