configure: Don't build qmake with MAC_SDK_FLAGS, it's a host tool

Passing -sdk to configure should affect the target build, not host tools.

Change-Id: I3902355715234b9300a65d3095b9c925d9492311
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Clean up handling of SDKs on MacOS/iOS

Instead of setting -isysroot in both arch.test, compile.test, the iOS
mkspecs, and in sdk.prf, we now propgate the chosen SDK as the qmake
variable QMAKE_MAC_SDK, which is then handled exclusivly in sdk.prf.

The QMAKE_MAC_SDK variable, and -sdk argument to configure, is expected
to be of the short-form name, eg macosx or iphoneos, not a full path, as
that's what Xcode also expects. We take care of translating that into
a full path for -isysroot/-syslibroot in sdk.prf, using xcodebuild as
a helper.

Change-Id: I27de1ed318cd8bbfae2a95c33e23edb5187a0265
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Don't evaluate makespec twice

Conflict resolution in ce15d972b8a265da157c5134bb6e87c58c427057 brought
in both versions of the conflict, ending up evaluating the makespec
twice.

Change-Id: I4b408dd0a7bfd538c741d7dd64732beb05136b88
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Fix Cocoa platform plugin build after merging master

Change-Id: I5a54ac961e42d34cb8a682bf1f14d3bb9a284269
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
iOS: network should not link against CoreServices on iOS

Change-Id: Ia3e21a3d73f696f0e77c427bdb263333646c48d3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
iOS: add QIOSOrientationListener

QIOSScreen will use this to listen for orientation
changes from UIDevice.

Change-Id: I5a30f3808f8b9b885303608ce2fc1316c962898b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
iOS: let QIOSScreen start/stop listening for device orientation

From the qpa docs, we only need to listen for device orientation
if orientationUpdateMask is non-zero

Change-Id: Id5e828cdff9a08794c8a029e11763cc037e1b959
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
iOS: add function convertToUIOrientation

Change-Id: I6145121d49eb3f5bab3f2a1ba57c779ec0b01023
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
iOS: add QIOSViewController

We need our own viewcontroller to better control which
orientations iOS can enter, and also ito be able to
stop auto-rotation.

We stop auto-rotation to happend by default, since this is
how Qt wants it (it is seen as the responsibility of the
application).

Change-Id: Id07a96e355396752fffd28984af528aeb0b7c3e3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
iOS: handle content orientation feedback from application

Change-Id: I2bfb4ee4840086dcd3ec85c2ee7e8769e76d2700
iOS: implement requestWindowOrientation

The application is normally supposed to rotate the content on its
own, but can call requestWindowOrientation to ask the window
manager to do it instead. This way of integrating orientation with
the OS is fragile, because:
1. In some cases, you cannot stop the OS from rotating at all
    (tablets).
2. It would be more safe to inform the window manager up-front
    which orientations it could rotate into, rather that relying
    on a function you call call to force this later on.
3. When the QML application starts, its a bit late to inform
    the platform plugin that it supports e.g landscape. If the
    OS is in landscape already, the plugin must still assume that
    the app operates in portrait (doing rotating on its own) until
    requestWindowOrientation is called. This might cause the app
    to first start up in portrait, just to rotate into landscape.

On iOS, it seems like we can handle the first two cases. The third
need some more investigation. We should anyway investigate if we
need some adjustment to the Qt API.

Change-Id: I50638b78d469ab70820a787de86a2f1981470786