Branch can be implicitly determined via the repo.

Using new function raise_if_error() of GitPython 3.1.25:
https://gitpython.readthedocs.io/en/stable/tutorial.html#handling-remotes

This makes it possible to integrate a project branch into different
branches of the same manifest project.

BCS 746-000808

The integration branch was reused even if there where new commits on the
target branch, which could lead into reverting some changes.
This adds a check, if the existing integration branch is directly based
on the target branch and deletes it if not.

Rename variable JENKINSGUF_SSH_PRIVATE_KEY / SSH_PRIVATE_KEY to
GITLAB_PRIVATE_KEY on this occasion, because it contains a private key
that was generated exclusively for this use case. The according public
key has been added as a deploy key in GitLab to all repositories that
this repository needs access to.

Add more detailed documentation concerning this configurationdirectly in
the gitlab-ci files.

The deploy_gitlab_ci now creates the integration commit and branch in
each passed subproject and create an integration commit in the manifest
containing all these new revisions.
A build is then triggered on this commit to test the functionality.

Split the update_submodule functions to reuse them in different ways.
Remove some previously used files.

BCS 746-000740

The merge job of a subproject include in the merge request merged by
gitlab ci, should not merge the integration branch in the manifest by
themself. This is now disabled by checking the source branch name.

This allow to merge the manifests commit at last.

Before only the ID was used but the CI_OPEN_MERGE_REQUESTS variable has
the complete path.

The project name is matched with the predefined gitlab var CI_PROJECT_NAME,
which uses lower case.

Added default source revision file name to common.py.
Modified the integration_into_manifest function to set the
corresponding subproject hash in the SRCREV.conf file if the
repository is not found in the default.xml file. The
merge_into_manifest function now works even if the names of
the master branches in the manifest and in the project
repository are different.

BCS 746-000016

The function used to rely on the given merge request object without
checking its current state. If the given object was not in one of the
"unchecked" states, it returned immediately. The state, however, could
have changed between its last query and the call of this function, so
it now checks the state first before deciding anything.

Unfortunately, GitLab still interpreted three of the four dashes as
start and end of YAML syntax, so we go back to two dashes.

The former "---" was still rendered as YAML syntax by GitLab in some
cases.

Restore the "---" separator which was removed in a previous commit. The
description simply must not start with this separator. If we include it
only in between the blocks, all instances are rendered as a horizontal
line, which makes the MR description more readable. Include a helper
function for this purpose, which extracts the message body from a commit
message.

GitLab renders "---" as a horizontal line or as a frame. We do not want
this, so replace it with "--".

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.

* Add retrigger_mr_pipeline_py script
* Move get_merge_request() function to separate file and make it return all
  available pipelines instead of just one
* Add helper script for parsing projects from manifest file