Fix: alt+f4 changing display mode

[phu54321]

input.getKeyState accepts beatoraja key index, not libgdx keycode.

I guess this would have been an obvious typo.

[Arctice]

I understand the error, but I'm not convinced this is the right way to fix it? Changing the code to directly calling into gdx rather than using the existing input support seems odd. In particular, while #168 isn't merged yet, I'm not sure this method will even safely work once render() isn't on the main thread.

[phu54321]

Rationale behind using Gdx.input.iskeypressed.

1. Its easy to understand.

2. Didnt knew Make Beatoraja Smooth Again #168 was ongoing: I was thinking of this other PR on the original beatoraja repo while implementing this.

exch-bms2/beatoraja#829

This PR attempt to use getasynckeystate instead of gdx.input.iskeypressed on a polling thread. I'm noticing some key drops so this might require alternative backend like, jni-ing with raw input api on windows, but it is quite flexible. I'm not sure if this is better or processing key input on main thread is better, but I think polling thread is pretty norm, and making the game engine's main loop invariant to the exact time the it is run (not doing all the judging or scoring / maybe networking on multiplayer) seems less fragile to unexpected events.

On implementing that patch I had to make this commit.

exch-bms2/beatoraja@07a460c

Which is, cause alt+f4 is a windows event, it should be processed by windows event listener which also is what previous version of libgdx2 lwjgl / glfw key system used. This is not an exact rationale, but I guess to process something related to the OS it may be better to use a key system that is coupled with the event system. Which is Gdx.key.iskeypressed here.

3. IIRC Gdx.input.isKeyPressed is a read only operation on a fixed array so read operation is thread safe I guess.