iOS: Teach event-dispatcher to handle changes to run-loop mode at runtime

UIKit changes the run-loop mode during scrolling to UITrackingMode, which
presumably prioritizes touch events and other sources related to a
smooth scrolling experience. It signals this change by interrupting the
current run-loop pass, and the outer loop is responsible for re-entering
the run-loop in the new mode. Failing to enter the run-loop with this
new mode results in UIScrollViews losing their kinetic feel when
flicking. This can be observed by e.g. bringing up the Emoji keyboard
and scrolling it horizontally.

We keep track of the current run-loop mode by listening for push and pop
notifications on the UIApplication object. The current mode is then used
in our Q_FOREVER-loop when re-entering CFRunLoopRunInMode.

For now we don't add our posted event source or timer source to the
new modes, under the assumption that the system prefers to limit the
number of sources that will fire during scrolling. If this turns out
to give a bad user-experience for Qt applications we should consider
changing it.

Change-Id: I3a612b3cfc77c74b658963057732dc4d61684df8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
iOS: Implement hasPendingEvents() in the event dispatcher

As we're using CFRunLoopIsWaiting() to check for the possible presence
of system events hasPendingEvents() will never return false if called
on the main thread. We assume clients will not use this function to
determine whether or not to call processEvents(), but instead use the
return value from processEvents.

Change-Id: Ifd63892c6d35bb7da204072616bfe3ee69ca1d85
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>