BCS 746-000808

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

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

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.

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

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 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.

Previous solution did not work because lxml does not support XPath 2.0 syntax.

Add support for finding projects in the manifest which have a namespace
prefix, even when only the plain project name is given.

* Before, only the latest commit was included
* Use merge request ID instead of branch name and commit in the argument list