Rewrite ModuleLoader

===================
Problem description
===================
The ModuleLoader class as it exists before this patch has a number of
serious problems:
  - It instantiates modules over and over again everywhere a
    Depends item appears. The different instances are later
    merged in a hopelessly obscure and error-prone way.
  - It seriously pollutes the module scopes so that sloppily written
    project files appear to work even though they shouldn't.
  - Dependencies between products are handled twice: Once using the
    normal module instantiation code (with the Export item
    acting like a Module item), and also with a parallel mechanism
    that does strange, seemingly redundant things especially regarding
    transitive dependencies, which appear to introduce enormous
    run-time overhead. It is also split up between ModuleLoader and
    ProjectResolver, adding even more confusion.
  - The code is messy, seriously under-documented and hardly
    understood even by its original authors. It presents a huge obstacle
    to potential contributors.

=================
Patch description
=================
- Each module is instantiated once per product. Property values are
  merged on the fly. Special handling for dependencies between
  products are kept to the absolutely required minimum.
- There are no more extra passes for establishing inter-product
  dependencies. Instead, whenever an unhandled dependency is
  encountered, processing the current product is paused and resumed
  once the dependency is ready, with the product state getting saved
  and restored in between so no work is done twice.
- The ModuleLoader class now really only locates and loads modules.
  The new main class is called ProjectTreeBuilder, and we have split
  off small, self-contained pieces wherever possible. This process
  will be continued in follow-up patches (see next section).

=======
Outlook
=======
The ProjectTreeBuilder ist still too large and should be split up
further into small, easily digestible parts with clear responsibilities,
until the top-level code becomes tidy and self-documenting. In the end,
it can probably be merged with ProjectResolver and Loader.
However, this first requires the tight coupling between
ProjectTreeBuilder/ModuleProviderLoader/ProbesResolver/ProjectResolver
to be broken; otherwise we can't produce clean interfaces. As this would
involve touching a lot of otherwise unrelated code, it is out of scope
for this patch.

=================
Benchmarking data
=================

We first present wall-time clock results gathered by running
"qbs resolve --log-time" for qbs itself and Qt Creator on macOS
and Windows. The numbers are the average of several runs, with
outliers removed.
Then the same for a simple QML project using a static Qt on Linux
(this case is special because our current way of handling plugins
causes a huge amount of modules to be loaded).
Finally, we show the output of the qbs_benchmarker tool for
resolving qbs and Qt Creator on Linux.
The data shows a speed-up that is hardly noticeable for simple
projects, but increases sharply with project complexity.
This suggests that our new way of resolving does not suffer
anymore from the non-linear slowdown when the number
of dependencies gets large.

Resolving qbs on Windows:
  Before this patch: ModuleLoader 3.6s, ProjectResolver 870ms
  With this patch: ProjectTreeBuilder 3.6s, ProjectResolver 840ms
Resolving Qt Creator on Windows:
  Before this patch: ModuleLoader 17s, ProjectResolver 6.8s
  With this patch: ProjectTreeBuilder 10.0s, ProjectResolver 6.5s
Resolving qbs on macOS:
  Before this patch: ModuleLoader 4.0s, ProjectResolver 2.3s
  With this patch: ProjectTreeBuilder 4.0s, ProjectResolver 2.3s
Resolving Qt Creator on macOS:
  Before this patch: ModuleLoader 32.0s, ProjectResolver 15.6s
  With this patch: ProjectTreeBuilder 23.0s, ProjectResolver 15.3s

Note that the above numbers are for an initial resolve, so they include
the time for running Probes. The speed-up for re-resolving (with cached
Probes) is even higher, in particular on macOS, where Probes take
excessively long.

Resolving with static Qt on Linux (QBS-1521):
  Before this patch: ModuleLoader 36s, ProjectResolver 18s
  With this patch: ProjectTreeBuilder 1.5s, ProjectResolver 14s

Output of qbs_benchmarker for resolving qbs on Linux:
    Old instruction count: 10029744668
    New instruction count: 9079802661
    Relative change: -10 %
    Old peak memory usage: 69881840 Bytes
    New peak memory usage: 82434624 Bytes
    Relative change: +17 %

Output of qbs_benchmarker for resolving Qt Creator on Linux:
    Old instruction count: 87364681688
    New instruction count: 53634332869
    Relative change: -39 %
    Old peak memory usage: 578458840 Bytes
    New peak memory usage: 567271960 Bytes
    Relative change: -2 %

I don't know where the increased memory footprint for a small project
comes from, but since it goes away for larger projects, it doesn't seem
worth investigating.

Fixes: QBS-1037
Task-number: QBS-1521
Change-Id: Ieeebce8a7ff68cdffc15d645e2342ece2426fa94
Reviewed-by: Ivan Komissarov <ABBAPOH@gmail.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>

2 files changed, 2 insertions, 2 deletions

diff --git a/share/qbs/modules/cpp/GenericGCC.qbs b/share/qbs/modules/cpp/GenericGCC.qbs
index 22a98ad57..05ceccf5f 100644
--- a/share/qbs/modules/cpp/GenericGCC.qbs
+++ b/share/qbs/modules/cpp/GenericGCC.qbs
@@ -216,7 +216,7 @@ CppModule {
     linkerScriptFlag: "-T"
 
     readonly property bool shouldCreateSymlinks: {
-        return createSymlinks && internalVersion && ["macho", "elf"].includes(cpp.imageFormat);
+        return createSymlinks && internalVersion && ["macho", "elf"].includes(imageFormat);
     }
 
     readonly property bool shouldSignArtifacts: codesign._canSignArtifacts
diff --git a/share/qbs/modules/qbs/common.qbs b/share/qbs/modules/qbs/common.qbs
index 7723c6050..8b31092a9 100644
--- a/share/qbs/modules/qbs/common.qbs
+++ b/share/qbs/modules/qbs/common.qbs
@@ -102,7 +102,7 @@ Module {
     property path installSourceBase
     property string installRoot: project.buildDirectory + "/install-root"
     property string installDir
-    property string installPrefix: qbs.targetOS.includes("unix") ? "/usr/local" : ""
+    property string installPrefix: targetOS.includes("unix") ? "/usr/local" : ""
     property path sysroot
 
     PropertyOptions {