QXcbSystemTrayTracker::trayWindow compiles if Q_XCB_DEBUG is on

Fixes qxcbsystemtraytracker.cpp:125:134:
error: 'connection' was not declared in this scope

Change-Id: If881aa9466ea94d5392da9f177e4b79e044710b7
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Move iOS makespec out of unsupported directory

It's a supported platform from 5.2, and we want build-scripts/CI/etc to
adapt to the change as soon as possible.

Change-Id: I8c78351191f59a6ecab33acc0829d2535379c787
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Simo Fält <simo.falt@digia.com>
iOS: Bump minimum required deployment target to 5.0

Apple only provides simulators for 5.0+, and we now rely on 5.0+ APIs.

Change-Id: I9ec047767b5f5e1b33aeef186ec6aff2b9c70a05
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
iOS: Rewrite CoreFoundation event-dispatcher

Instead of having separate code-paths for QEventLoop::EventLoopExec
and the non-blocking processEvent() we now have a single Q_FOREVER
loop where the logic can be shared. We make multiple loop-passes,
each time calling CFRunLoopRunInMode with potentially different
arguments, depending on the result of the previous run.

For the EventLoopExec case we'll continue making loop-passes until
the event-loop has been interrupted. For the non-EventLoopExec case,
we respect interruption, but will continue making loop-passes only
until we've processed all events in the queue, optionally waiting
for the initial event if WaitForMoreEvents is set. Limitations in
the CoreFoundation APIs unfortunately force us to keep some state
on whether or not we've processed events and timers for a given
processEvents() pass (with corresponding deferred scheduling of
timers and event source signaling).

The way we handle timers has also been rewritten to no longer defer
the timer activation to a special timer source. The constraint of
CoreFoundation timers is that they can not recurse (re-fire) in a
callback, but that only applies per timer, so using multiple CF
timers allows us to recurse. We still only use a single CF timer
for all the Qt timers though, and only spawn a new CF timer if
the user calls processEvents() inside a timer callback.

This commit removes the logic related to dealing with UITrackingMode,
as that logic was slighly problematic, but the feature will be
added back in a follow-up commit, in line with the new approach.

The result of this commit is that we're passing all event-loop,
event-dispatcher, and timer auto-tests, both for the QtCore dispatcher
and the GUI event-dispatcher.

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