GlobalShortcutWin: try to make WinHooks do less work.

This change switches GlobalShortcutWin over to a slightly different model
in an attempt to combat the WinHook timeouts users have been reporting.

Previously, the DirectInput poller and the WinHooks event handling lived in
the same high-priority thread, and both of them processed all incoming button
events. Since both of them processed all events and emitted them using
GlobalShortcutEngine's handleButton method, they had to live in the same
thread in order for us to control the order of the signal dispatch.

Having the WinHooks live in the same thread as the DirectInput polling meant
that the hooks could potentially be blocked every 20 ms by the DirectInput
poller's timer event, which wasn't really desirable.

This new model splits up the DirectInput poller and the WinHooks event handling
into two separate, high-priority threads, each with different responsibilities.

The DirectInput poller is now the main source of events. This is where the actual
global shortcut presses are handled. Having DirectInput responsible for all
global shortcut buttonUp and buttonDown events allows us to use the WinHooks
thread *just* for filtering suppressed keys.

This design allows our WinHooks to have their own thread and event loop, meaning
they won't have to fight the DirectInput polling timer. Also, since the WinHooks
now have a more restricted set of tasks, they're able to do less work, hopefully
making it harder to trigger a timeout.