establish syntax & semantics for constraining dependencies

Requirements

currently, the only available constraints for any particular dependency are the module name and version. the idea is to generalize this to arbitrary module properties, for example target OS and architecture, toolchain vendor and version, exception model, and other ABI parameters, to optional features, etc.

the rules established herein can be applied to filtering already available modules (QBS-995), to determining which external module variants are made available by providers (relates QBS-1604), and to determining which module variants are built internally (QBS-1197).

due to the generalization, the following considerations become relevant:

• it is desirable to support "soft" constraints which express a preference if multiple variants of the same module are available, e.g. "threadsafe: false", or "newest/oldest matching version".
  • a preference set may contain multi-dimensional constraints, for example dynamic-release, static-release, static-debug, but not dynamic-debug
• it must be possible to apply constraints to all dependencies within a product or even project
  • when applied to a project, sets of products with different configurations (multi-target builds) must be supported
• it must be possible to apply constraints from the command line
• this must play nicely with profiles, which are probably also key to addressing multi-target builds (QBS-1602)
• this must play nicely with explicit product multiplexing (QBS-1526)

Use Cases

TODO

Proposal

TODO