clutter: Deliver events sooner when possible.
Previously all events would be queued and their processing deferred till the next master clock tick, at which point supersesed input events would be dropped and only the latest of each type used. This was great for minimizing CPU usage but had two drawbacks: * Clients would receive the next input event after it is already too late to make it to the next compositor frame. * Clients would receive a lower resolution event stream than the hardware is capable of. We now instead scale performance dynamically according to available time. If there is enough idle time available then that will be used to deliver events immediately without delay. Otherwise event delivery will scale down to the old minimal-CPU behaviour. This allows clients to receive input events sufficiently in advance of the next compositor frame that they can respond and redraw with one frame lower latency than before. It also allows clients higher resolution input, in case they are able to use it. GNOME/mutter!168