support multiple module providers for one module

Module providers have been implemented as a way to dynamically generate qbs modules for external packages. however, the implementation has some limitations: providers must be namespaced, so they can serve only a specific framework (this implementation was obviously targeted at qt, and was used to supersede qbs-setup-qt). also, each module/framework can be served by only one provider. when no specific provider is found for a module, the "fallback" provider kicks in (unless it is disabled). the fallback provider is limited to using pkg-config and is not extensible.

instead, providers should be able to operate without namespace, and multiple providers should be able to serve the same namespace. within this new framework, the "fallback" provider should be repurposed as a "pkgconfig" provider.

as a consequence of competing providers being potentially available for the same module, it must be possible to select and prioritize providers. for that, we need for example a qbsModuleProviders property which can be set in in Project, Product, and possibly Depends scope (the last has ramifications for merging modules), and can be overridden in profiles and on the command line. the default of this property should be filled by collecting the various available providers and sorting them by a new priority property of the ModuleProvider Item. old-style "scoped" providers shall be prioritized over new-style "named" providers, on the assumption that they are more specific; prioritization within that group is unnecessary, as each module is handled by at most one scoped provider.

it is not reasonable to implement the fallback chain via conditions inside the providers:

• this requires that providers know about each other, which breaks modularity and extensibility
• it limits the possible lookup order(s) to whatever is hard-coded
• it requires a much more complete setup of the evaluation context

note that the provider activation order effectively overrides module priorities. this is already the case in the old scheme, where the search order of the source types is imposed by the fallback provider's implementation (and so far, there is actually only one - pkg-config).

it is not quite clear what the meaning of the legacy property Depends::enableFallback should be. should it refer to non-namespaced providers in general?

whether native qbs module files should be handled as a provider as well is debatable; the issue is discussed in QBS-1658.

requirements

• it should be backward-compatible with old code - suggested syntax: not setting qbsModuleProviders at all (default populated value is used)
• it should be forward-compatible with Qt provider when it's no longer scoped - suggested syntax: qbsModuleProviders [Qt] (this should be true for all scoped providers)
• it should be possible to select specific provider(s) - suggested syntax: qbsModuleProviders: [providerA, providerB]
• if multiple providers generate equally named modules, they should be prioritized based on the order in the list (e.g. system Qt can override conan-qt if qmake is in PATH - qbsModuleProviders: [Qt, conan])
• it should be possible to disable all providers (incl. Qt) - suggested syntax: qbsModuleProviders: []
• it should be possible to set qbsModuleProviders on the Product and Project level (both in items and via CLI) - qbs resolve project.MyProject.qbsModuleProviders: providerA

nice-to-haves

• ideally, it would be possible to set qbsModuleProviders per-module (in Product and Project items and via CLI), to be able to selectively disable the usage of broken 3rd party data that particular providers use
  • this could be done via packages (QBS-1452) - suggested syntax: packages.<packageName>. qbsModuleProviders: providerA
• ideally, qbsModuleProviders could be changed without specifying the entire new value (QBS-1669)