make coin generic enough to build arbitrary products

We have qt projects that have multiple dependencies to other products, such as

• qt-automotive
• qtcreator
• ...

but we cannot build these modules in CI, because it currently supports only building 1 product as dependency.

the objective is to make is possible and simple to configure coin to build arbitrary "products".

the main milestones:

• introduce generic "products", and a way to express arbitrary dependencies between them.
• reduce number of workitem types. in particular, do away with provisioning items. instead, platform images are just products themselves and are simply built via builditems.
• implement a flexible configuration system and migrate the existing specialized config files and hard-coded rules to this new system.

This epic is the placeholder for all work that is required to integrate the changes to build multiple products in CI.

[Iikka] Proposal for concrete steps:

Step1: Base functionality to run a build for Platform product (~6-8 weeks)

1. Product Configuration interface  https://codereview.qt-project.org/#/c/237967/
2. Product Type class loader https://codereview.qt-project.org/#/c/221919/
   1. This includes ProductType_platform.py + PlatformBuildItem (a.k.a. current Provision(Work)Item)
3. Synthesize Platform product "ProductConfiguration" objects (i.e. test/build configurations)  https://codereview.qt-project.org/#/c/238666/
4. Refactor WorkItemFactory   https://codereview.qt-project.org/#/c/238650/

1. 1. Will instantiate the Product Type of the product and execute the build graph i.e. creation of WorkItems
2. "ProductConfiguration" properties are strings (OS, OS_VERSION, ARCH, etc.) but Coin expects to have enums (int): https://codereview.qt-project.org/#/c/236940/ 

Expected outcome:

• Basic structure to execute a simple build (workitemfactory replacement)
• Provisioning executed with the new system, i.e. building the Platform product

Step2: Run a build for qt5 (~8-10 weeks)

1. Minor adjustment into WorkItem interface: https://codereview.qt-project.org/#/c/239653/
   1. Keep compatibility with current system
2. Split modules.py per product: https://codereview.qt-project.org/#/c/239357/
   1. Keep compatibility with current system
3. Implement ProductType_qt5.py and ProductType_qt5_module.py
   1. For every forked-out submodule ProductConfiguration there already exist code to produce AgentInstructions (2)
   2. Create BuildItem and TestItem per forked-out submodule ProductConfiguration and set AgentInstructions directly (1)
4. Synthesize qt5 configurations using the "ProductConfiguration" interface
5. Implement "Build Context"
   1. Not covered at all yet (QTQAINFRA-2209)
6. Run qt5 build

Expected outcome:

• qt5 build

Step3: Run a build for some product, e.g. tqtc-qt5 (~2 weeks)

1. Synthesize "ProductConfiguration" objects: now we have product level depency chain: tqtc-qt5 -> qt5 -> platform
2. Run the build for tqtc-qt5

Expected outcome:

• tqtc-qt5 build
• system should re-use existing qt5 and platform build artifacts (if using refs from previous builds/steps)

Step4: Translate current platform configurations from upstream into "ProductConfiguration" object tree (~4-6 weeks)

1. While the parser is not functional yet we can translate the current parsed configurations into "ProductConfiguration" object tree and run the build
2. QTQAINFRA-2081

Expected outcome:

• A build executed based on the test configurations defined in actual qt5, but using the new Product Repo system

Step5:
Step6:
...