Adapt configure.exe to use qmake to do most of the work of configuring
Qt. This unifies a large part of our configuration system between Unix
and Windows. configure.exe is now still doing the license check,
creating qconfig.cpp, building qmake, and not much more.

On the way, re-implement the still missing Windows-specific tests with
the new system.

The opengles2 vs. opengl-desktop conditions got a bit convoluted, as
Unix prefers desktop GL, while Windows GLES2 (via ANGLE). Superficially,
there is a circular dependency, but the platform scopes are supposed to
break it.

Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: Ia1941f2c34b7f5bd4990a7673cd737361381c2e7
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>

specifically, make configure.bat dump the text file (which got some
windows-specific adjustments).

incidentally, this change removes the need for including a pre-built
configure.exe into our source packages.

Change-Id: Ib3515c113f3602767554fe1493df226551a7bf10
Reviewed-by: Lars Knoll <lars.knoll@qt.io>

that is, save it to config.opt and recall it when -redo is used (and do
not write it again in this case).

a trivial config.status is still created, as having it is very
convenient when shadow-building.

Task-number: QTBUG-38792
Change-Id: I5e9f7374d6bfc60c427cbfd5e9b3e68bfcaae9f2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>

it is sometimes desirable to override values from the mkspec without
modifying (or wrapping) the spec itself. linux distributors do this on a
regular basis.

so far, we'd pick up CFLAGS, etc. from the environment, in a somewhat
autoconf-like fashion. however, over time, this approach proved
problematic: the concept doesn't mix particularly well with mkspecs to
start with, is unexpected (and therefore causes frustration), and
doesn't mix well with cross-building (at least the way it was realized).
ironically, it was implemented this way (quite a while ago) upon my
explicit request ...

the new mechanism uses explicit variable manipulations on the configure
command line, just like qmake itself understands. as it happens, this is
again quite similar to autoconf-generated configure scripts. however,
this time around we don't pretend to be actually autoconf-like, so we
also don't try to map any variable names (some of which have different
semantics anyway).

this commit also eliminates the last use of the QMakeVar() function,
so delete it and the underlying infrastructure.

Task-number: QTBUG-32530
Task-number: QTBUG-42962
Change-Id: Id31a6b80e1add08ca21f5b178614bda530d12374
Reviewed-by: Lars Knoll <lars.knoll@qt.io>

Add the command line options supported by the windows version of
configure and respect them when running our configure tests.

Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: I1206d60a177e251540d34d232c73c930847564b3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>

it's really a bit weird that the windows configure has more options to
configure unix features than the unix one, even if some are just
workarounds for missing auto-detection.

unlike in configure.exe itself, -posix-iconv is now also understood for
symmetry with -gnu-iconv and -sun-iconv.

Change-Id: Ic15376e5822e43b998bd17f02c11e5dd0567dc2b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>

- remove the redundantly listed -no-* options and indicate the defaults
  differently
- completely regroup the options into somewhat logical sections

Change-Id: Iaa87c2f3749944cd3fc2ec18975767c04892f746
Reviewed-by: Lars Knoll <lars.knoll@qt.io>

Add protocol-specific code and the QSctpServer, QSctpSocket classes.

Change-Id: Ie9a1d87bd1fda866a2405043d1c15c12ded5a96e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

These arguments were nonsensical, as they would lead to every single Qt
module linking to those libraries. This was probably some left-over from
old times, when Qt was just a single library.

Change-Id: I0343a6df270fd0d2efa5333ba4e457670f5d0910
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>

Since the system proxies are on by default now then we turn off
libproxy support by default so that there is no risk of a conflict
occurring.

For instance on Linux, it is possible that libproxy indirectly causes
KDE 4 libraries to be loaded which will cause a conflict with the Qt 5
libraries. Therefore we turn it off by default, since the system
proxy setting is the overall better one to have.

[ChangeLog][Important Behavior Changes][QtNetwork] libproxy is now
turned off by default. Configure with -libproxy in order to enable it
again.

Task-number: QTBUG-53649
Change-Id: I0c6c5b9091dc2b2b7662fd44f2a1b49c622e563f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
Reviewed-by: Richard J. Moore <rich@kde.org>

By changing the system proxies option default to being on, we
set it to be the more natural default setting. This is down
to the fact that people tend to assume that this is already
the default option.

[ChangeLog][Important Behavior Changes][QtNetwork] Proxies from
system settings will now be used by default. Configure with
-no-system-proxies to disable.

Change-Id: Iec5bbde9dff1311ce44418f6aa024bda05388cf6
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Richard J. Moore <rich@kde.org>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Peter Hartmann <peter-qt@hartmann.tk>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>

Change-Id: If9c86c5bf9c6194f1ac282a657f9967f4fa589b3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>