(lua) asynch out-of-loop input processing

[letoram]

This is needed to reduce input latency in special cases. The core of the problem is that since any input can possibly have an effect of the graphics context, it is undefined behaviour to process input events while the buffers are in-flight and further graphics buffers at this level is dangerously wasteful. The risk can be mitigated with more explicit synch, which is needed anyhow, but better yet is to have a Lua path that can filter out the "UI" relevant parts to the client one.

Plan:

• [x] new lua entrypoint for _input_raw
• [x] asynch / threaded event collection and direct-to-drain forward to input_raw
• [x] call with a fenv that masks out other calls
• [ ] psep_open add ringbuffer in shared memory
• [ ] evdev: move identify/hotplug stage to psep_open
• [ ] evdev: read input events in monitor process into ring buffer

Open Question:

• ~~should re-queuing for local-visual inputs be up to the _raw handler implementation or happen depending on return result? easier for the developer, but more costly due to 1 additional pack/unpack stage.~~ Yes, use _input_end to inject non-forwarded buffer back into normal _input handler.

Notes:

• mostly makes sense for digital/translated inputs since mouse is more 'on-event' handler sensitive and harder to safely determine if the sample would yield anything (image_hit + mouse_input masking controls might mitigate).