rethinking qt modularization wrt. CI

the modularization of qt has introduced a number of problems:

1. we have a poor test coverage, which means that integrating modules separately significantly increases the chance of regressions slipping in. we are trying to counter this somewhat with reverse dependencies, but these have their own set of problems (dealing with expected incompatibilities is tricky).
2. as qt is de-facto still a single product despite the modularization, we are doing integration runs on the qt5 supermodule. due to point 1, many problems become obvious only in the qt5 integration run after they entered the module mainlines, which means that the qt5 integrations are often delayed, in the worst case by weeks if multiple issues come together.
3. for historical reasons, the package creation and testing system is another separate step, which makes the release process a quite tedious exercise.

obviously, this situation is not sustainable.

it is unrealistic that our test coverage will approach 100% at any time in the foreseeable future, so we must conclude that modularization was a failure as far as CI and releasing are concerned.

therefore we should un-modularize the CI system:

• there is only one "module" in the integration setup: qt5
• this means that we get full revdep coverage
• all changes staged for the same branch in different submodules are integrated at the same time
  • this conveniently introduces atomicity, and thus solves the problem introduced by revdeps in a modular CI
• when an integration succeeds, the supermodule sha1 are instantly updated as well
• the CI should also test the packaging stages, so we have end-to-end coverage

this approach obviously rather significantly increases the performance demands of the system, so we need to apply some breakthrough optimizations. these are covered by the dependencies.