new config system needs support for per-submodule configs

the new product config system (QTQAINFRA-1652) leaves the actual building of the products up to "product type factory classes". these classes can consume arbitrary properties from the product definitions, which makes the system very flexible.

for products with submodules (e.g., qt5), each submodule may require build system options which are specific to this module. as supermodule products configure not only their build as a whole, but also independent integrations of their submodules, it must be possible to configure the options at submodule granularity.

with the facilities designed so far, this would be achieved this way:

   "product": "qt5",
   "product_type": "qt",
   ...
   "qt-configure-qtconnectivity": "-feature-bluez",
   ...

i.e., the "qt" type recognizes properties with the "qt-configure-" pattern and passes them to configure/qmake along with other options derived from the set properties. builds of the supermodule would use the options from all submodules which passed the submodule filter ("qt-use-for", or whatever property name we agree on in the end).

—

a significant use case of this feature is making sure that particular builds (most of all, packaging builds) break when certain features' dependencies are not satisfied, rather than silently omitting these features. this is achieved by adding configure options which explicitly enable particular features.

to make this as fail-safe as possible, it has been suggested to give as much control over the options as possible to the module maintainers, and as little as possible to "the CI guys". this would imply decentralizing the submodule configuration, i.e., storing it inside each submodule itself.
as an undeniable upside, this would make it possible to atomically add a feature and ensure that CI actually tests it.
otoh, this obviously adds complexity, and makes the system less accessible to those concerned with the top-level view (RM).
the configurations inside the submodules would somehow need to be mapped to the configurations in the supermodule, which would probably imply assigning identifiers ... somehow. when adding a new configuration which requires different submodule configurations (e.g., a platform that doesn't support certain features), possibly multiple submodules would have to be prepared separately first, which would be quite some work, and would be non-atomic in turn (the submodule configs aren't tested until the supermodule is integrated).

ultimately, i would argue that the atomicity issue should be addressed via QTQAINFRA-868, and release brown paper bag bugs should be avoided by actually reviewing the configure output as part of the release checklist.