Also set yocto deploy job to manual to test merge.

As all projects are commited in the same branch the 'up-to-date' check
may not only check if the first parent commit points to the
master/dunfell branch. Now it is needed to loop through the history
until the integration branch's commit is found.

On fail a message is displayed which merge request needs to be
retriggered manually. This can now also be the 'parent'-MR that
triggered the complete chain.

The check job is used pipeline again.

The retrigger job also looks in the .gitlab-ci project for check jobs to
retrigger.

Allow deploy_gitlab_ci to change multiple projects at once.
Use it to create integration branches and merge requests in all
projects.

Add a python file to generate a job yml from jinja2 template.
Add a template for the jobs to trigger. These execute the actual
integration in all 'subprojects'.
Create the yml file in the deploy job and trigger it in a new trigger
job.

Also add all yml files to the yamllint check and replaces the project
path check with a more general project-root check.

BCS 746-000646

The markdown2 Python module was added to the package_release.py script,
which resulted in a failed SDK deployment because it was missing from
the build container. Updated ci-images to the latest revision, in which
the module was added to the build container.
Modified package_release.py to skip the metadata generation when
deploying the SDK.

BCS 746-000727

BCS 746-000716

BCS 746-000715

Add .yamllint.yml to configure the yamllint usage, should
be used as master yamllint config from other stages also.
Apply small changes to yml files to match yamllint.

BCS 746-000640

BCS 746-000669

The job was used to check if all scripts are able to run in the yocto
CI image. Tim and Jonas decided to remove the job and plan to change
the CI, that the yocto image does not need to execute special python
scripts. That way we may use the plain crops/poky container for the
yocto build and remove this dependency thats hard to track.

BCS 746-000643

The variable use in the deploy name was not replaced in the UI. This
hopefully cleansup the UI, and uses the project root variable in the job
only.

BCS 746-000629

Fix pylint errors introduced with new pylint version:
* unspecified-encoding: explicitly set encoding when opening a file
* assigning-non-slot: use "set_reference()" function instead of assigning
  a value to the "reference" attribute
* unused-variable: remove "e" variable on exceptions when not referenced

The outdated YAML 1.1 specification allowed values like 'yes' or 'no'
for boolean fields [1]. The newer spec 1.2 allows only 'true' and
'false' [2], so we update them to be conform with it.

[1]: https://yaml.org/type/bool.html
[2]: https://yaml.org/spec/1.2.2/#10212-boolean

The testsuite is generated per platform and submited to the lava server.
The resulting jobs are monitored and the results are downloaded in the
results/ subfolder.

The jobs in the deploy stage have to be triggered manually in GitLab.
There is one deploy job for each project which uses the gitlab-ci
scripts as a submodule, so that the deployment can be performed step by
step.

If executed within MR context, an integration MR is created and left
open. The user can extend this integration MR, e.g. if CI scripts have
been renamed, changed command line arguments or other changes requiring
updates of the correspronding .gitlab-ci.yml file. Subsequent runs of
this job will re-create the integration branch, so manual changes are
lost in this case.

If executed on the master branch (i.e. after the source MR has been
merged), the job does exactly the same, plus the integration MR will be
automatically merged. If this fails, the job will fail as well.