Deploy QtWebEngineCore as a Qt module

This delegates the linking step from ninja to qmake so that we can
let qmake decide the destination of the target itself, easing the
deployment and installation logic across platforms.

The module is only deployed as a binary and no header are available
outside of the source tree. This is only to make sure that the
dependence of the QtWebEngine and QtWebEngineWidgets libraries on it
is resolved at runtime exactly the same way as with other Qt modules,
on all platforms.

Ninja still takes care of the compilation and gyp lets qmake know how
and what to link by dumping the list of flags and input files in a
generated .pri file.

This has to be done in a separate .pro file so that we can make sure
that ninja is run inconditionally before make reaches the dependency
check in core_module.pro, ensured by the parent Makefile.

Note 1: This patch removes RPATH hacks that are no longer necessary

Note 2: Other targets like ffmpegsumo are still linked by ninja. The
same logic could be moved to a qmake file but this require some more
work to make sure that some switches (e.g. -stdlib=libc++) are
coordinated between gyp and qmake.

Change-Id: If65968547bde5b9cf732e31e97931c17ae1921a7
Reviewed-by: Zoltan Arvai <zarvai@inf.u-szeged.hu>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
Do not pass linking information from qmake to gyp and to qmake again

Instead make sure that the QT and QT_PRIVATE variables are identical
in both core_gyp_generator.pro and core_module.pro, the former for
compilation and the later for linking.

This allows working around issues of qmake when handling -l switches
in libs. Some features on Windows append version numbers, while this
is not done when linking to Qt libraries via the QT variable.

Change-Id: I04b58a313335daeffc9510471553517c63908852
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
Use the shadow build directory for the ninja output

The gyp/ninja build is moved from out/(Debug|Release) to
src/core/(Debug|Release).

The ninja build as well as generated gyp files and python
intermediate files all stay in the source tree for the moment.

Change-Id: I6948380c45896540fe508238ceef9fe48e41f5af
Reviewed-by: Zoltan Arvai <zarvai@inf.u-szeged.hu>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
Fix debug_and_release builds

This makes sure that gyp_run.pro follows the same behavior as
core_module.pro and that ninja is run for each config, in the
appropriate directory.

A special .NOTPARALLEL make fake target is added to avoid running
ninja for both configurations in parallel (this would cause build
failures). This target will be ignored by nmake, but might cause
issues if trying to build with jom.

Change-Id: Ibaa5f6aa4972cb24c83cc7a63e496938a5c16a3f
Reviewed-by: Zoltan Arvai <zarvai@inf.u-szeged.hu>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
Do not use the system ninja

Always bootstrap and use the bundled ninja to avoid incompatibilities
between our bundled gyp and the system ninja, which might be quite
old.

This patch also removes the ninja location caching, as updating the
cache would trigger a re-run of qmake and gyp on all the project,
while the benefit of using the cache in this case are low.

Change-Id: I843cbe20e1153caecbda00ab3d45a34d560b2423
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
Reviewed-by: Zoltan Arvai <zarvai@inf.u-szeged.hu>