Explicitly triggering a pipeline in the target repository does not work
easily from this place because we would have to distinguish between the
manifest (which uses branch pipelines) and the sub-projects (which use
merge request pipelines). This separation should not be hard-coded here,
so we move the decision whether or not to run a pipeline to the
.gitlab-ci.yml file of the target. Reverting these two commits:

63279799
    deploy_gitlab_ci: trigger pipeline only if it has not run before

dfc6204a
    deploy_gitlab_ci: trigger pipeline on integration branch

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.