Improve handling of templates imported from other repositories

[jouvin]

I open this issue to follow up a discussion started by @jrha in template-library-examples issue.

Currently, a significant part of this repository is imported from other repositories (configuration-modules-core, configuration-modules-grid, AII...) during the release process. This workflow has (at least) 4 drawbacks:

1. The tests run successfully before the release may break during the release (or after) because the contents tested is not the contents released.
2. The tests run when modifying the source repositories are using the current version of this repository which doesn't include the templates possibly modified during a PR against the source repositories.
3. If something is broken in this repository during the release (because of the implied update), fixing the problem in the source repository doesn't fix the problem in the tests, as shown for example by Update the OS version definition for each server template-library-examples#42. This requires also to update the faulty template in this repository, generally manually.
4. There is the risk of fixing a problem in this repository without fixing the source repository, which will lead to a regression at the next release.

Solution to this problem is not necessarily trivial... The main goal of having everything in this repository is to ease the download of the template library core in Aquilon or SCDB. But probably, as we have scripts to do this now (get-template-library, plenary-template-library.py) we could probably do the work necessary to build the template library core on the fly by aggregating several sources.

The main issue is probably how the source repositories can make their templates part available to other repositories and scripts as part of the PR merge, as building these templates require processing their source files which is a potentially long process as it generally involves running the tests for the Quattor part hosted in the repository. One possibility would be to build an artefact, e.g. a tar file, as part of the PR build and/or deploy phase, that could be downloaded by scripts used to build the template library core. It could also help solving the second issue with CI scripts downloading the artefact corresponding to the PR when running tests, ensuring we are really testing the impact of all the potential modifications in the source repository.