Window event lock inversion

With Wayland and XCB (non-embedded) window providers, and probably in a way or another for most other window providers as well, there is a subtle lock inversion:

• On one hand:
  • The video output core takes the window lock to disable the window.
  • ...
  • The provider disable callback joins its event thread.
• On the other hand:
  • A keyboard event is received for the display server by the event thread.
  • The key event is passed to core for translation.
  • The translated action is passed to the hotkeys module.
  • The hotkeys module requests a full-screen mode toggle (for instance) from the player.
  • The player toggles the video output "fullscreen" variable.
  • The video output variable callback acquires the window lock to change the full-screen mode.

This leads to a race where the window lock is being held to disable the window right when an inconvenient input event is being processed by the same window. The event thread ends up waiting for the lock, which is held by the (video decoder?) thread that is trying to disable the window, which is waiting for the event thread to end.

We probably need to revive the hotkeys interface thread to process input events asynchronously.