On windows, `Gdx.input.isKeyPressed` uses lwjgl's event system
for fetching key inputs. This event-based system sometimes
lags due to OS issues, so beatoraja had problem getting key state
ASAP. When pressing multiple keys, some keys were registered
later than other keys.

This commit fixes the issue by utilizing Windows's `GetAsyncKeyState`
function for fetching current keyboard state itself. Note that this
function will poll key state regardless of whether the window is
focused or not, so this could be documented.

Reference: previous libgdx input polling system (from LWJGL2)

https://github.com/LWJGL/lwjgl/blob/master/src/java/org/lwjgl/opengl/WindowsKeyboard.java

…t focused

…lay.isActive()

Display.isActive() requires a global lock on the display object, so it frequently stalls, resulting in less-than-optimal gaming experience.

To make things lock-free, we again use JNA to implement `Display.isActive()` ourselves.

Note that this code is coded for lwjgl2 backend the beatoraja currently uses. To maximize modularity, All input-specific code are
confined in KeyPressedPreferNative class only.

Alt+F4 should kill the application.

Calling `Gdx.input.isKeyPressed` acquires lock of global some opengl mutex,
so it takes quite a considerable amount of time.

Filter out excessive calls with GetAsyncKeyState.

lwjgl already has implemented multiple JNIs for Windows APIs we need.
Since JNI is much faster than JNA, with a
help of various reflection help we use those
native methods instead of maintaining our own
c++/java JNI build native systems.

- Corollary: removed JNA dependencies