Add support for wildcarded project dependencies

[garonne <garonne@…>]

At the moment CMT does not support wildcarded project dependencies. This has two significant consequences:

1. It is not easily possible to test a new version of a project within the context of an existing project hierarchy.

2. In some cases a project changes faster than the version of e.g. a glue package to an external package. If a package within a higher level project only depends upon the version of the external package, the project needs to be versioned, even though no code changes have taken place.

Take the example of the tdaq-common project. To first order, it only depends upon the Boost, for which there is a glue package within the LCGCMT project. The Boost version is stable over periods of many months, but the LCGCMT project version changes much more frequently because other packages (e.g. ROOT) change more frequently. Thus currently tdaq-common would need to be changed and rebuilt at a rate that's at least as high as that for LCGCMT, even though nothing has changed. My proposal was that if a diamond project dependency existed (in our case AtlasConditions depends upon tdaq-common, which depends upon LCGCMT, and AtlasConditions also depends upon AtlasCore, which depends upon Gaudi and then LCGCMT), then as long as one leg of the diamond fully specified the project versions, the other leg could "weaken" the dependencies with some sort of wildcarding. Thus as long as exact versions of AtlasCore, Gaudi and LCGCMT were specified on one branch, then tdaq-common could specify a weak dependency against LCGCMT, and use the native_version package use statement described in 2. above to ensure that the correct version of Boost was used.

I believe a similar scheme could be used to insert an updated project version into an existing project tree for test purposes, although I haven't thought it through yet.

[garonne]

This is enabled and available for the next release. By defaut the highest release is choosen. E.g.:

2.0.3   2.0.4   2.1.4   2.1.5   2.1.6   2.2.1   3  3.0.1   3.1.1   v1      v2

• use v* will get 3.1.1
• use v2.* will get 2.2.1
• use v2.1.* will get 2.1.6

We apply the same logic than with package version notation, i.d.:

<any-letters>MajorId<any-letters>MinorId<any-letters>PatchId<anything>