Investigate latency issues with the tabwin popping up

If you alt+tab and then release really quickly, the tabwin will sometimes not come up at all (because you released before it mapped), and then the windows will not cycle. I'm not sure if this is because the tabwin is out of process and it just takes some time to send all the data needed to pop it up, or something else.

It may actually be unavoidable: xfwm4 manages input itself for the tabwin, so it doesn't rely on GTK to handle key presses and drive the cycling. I really liked the idea of just passing the keyboard shortcuts for everything to the UI process and letting it handle everything, but maybe that's not a good idea.

Maybe the compositor should do all the keyboard input processing for the tabwin and drive the window cycling entirely by itself. The tabwin can perhaps still handle pointer input, at least. This would put all the cycling logic/handling into the tabwin grab, which is maybe the best place for it anyway. It would also simplify the UI<->compositor protocol a bit, as the UI won't need to know about the keyboard shortcuts.