Don't assume that all CFPropertyListRef are CFArrayRefs

We might need more robust code in the future. But at least for this case
it looks like a CFStringRef is also a possibility.

Task-number: QTBUG-29776
Change-Id: Iaf50835122fcbb7e6e9c7fbf65e31e6143b2bc54
(cherry-picked from qtbase commit 1b08e0307dfebe561fbb0819a2d6b53edd8e8e93)
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Make sure to also check for null CFPropertyLists.

In 1b08e0307dfebe561fbb0819a2d6b53edd8e8e93, I removed the null check
by accident. It's possible for the Darwin API to return a null
property list.

Task-number: QTBUG-30760
Change-Id: Iaf0125767fe4b47c19810b70483a5219e94e4305
(cherry-picked from qtbase commit 96134c6f585963c9d449db17589f21e67519a2a8)
Reviewed-by: Denis Dzyubenko <denis@ddenis.info>
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Remove a left over cast that is now semantically incorrect.

CFPropertyListRef is a typedef for void*, which is why this code was
compiling OK prior to this change.

Change-Id: I67f2affeeb97459f85eedc8becb5d963557d34c3
(cherry-picked from qtbase commit fb25d6c7f6690402060027422343957c7d8ee718)
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Include <new> instead of <ciso646> for libc++ detection.

As usual, MSVC does things differently and its ciso646 header does
unexpected things, like #define'ing xor and causing all sorts of breakages.

Include <new> instead: it should be as inocuous as ciso646 should have been.

No backport because Qt5 does not have QT_NO_STL.

Task-number: QTBUG-32773
Change-Id: I01a48ec2c726367e9498aeec4efb42f49d68bbe4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>