Trying to query CI variables on a project which does not have the CI
feature enabled leads to an HTTP 403 (forbidden) error.
Check whether CI is enabled using the "jobs_enabled" flag.

The match to detect fngsystem still contained 'guf'. Changed to 'seco'.

BCS 746-001043

- Use "source" and "target" terminology in the script, just like in the
  GitLab CI variables.
- Spefify data types for function arguments.
- Rename function arguments to better reflect their data types.
- Move determination of integration branch into main function, so that
  the successfull status message can be more verbose.
- Remove parent_merge_request feature and checking for gitlab-ci
  integrations, because the check job does not run on gitlab-ci
  integration branches at all.

We don't need to explicitly trigger a build after merging changes in
gitlab-ci. A master pipeline on the target projects runs automatically.

TypeError: 'NoneType' object is not subscriptable

Example:
https://git.seco.com/seco-ne/yocto/manifest/-/jobs/129201

Previously we integrated all projects into the manifest, even those that
belonged to a different manifest branch. That led to all manifests
having the same project revisions, even if they should be different due
to different intgrated project branches.

Save a list of integration sources for each manifest branch separately
now, so that we can check which project belongs to which manifest branch
later.

TypeError: 'NoneType' object is not subscriptable
Example:
https://git.seco.com/seco-ne/yocto/infrastructure/ci-test/minimal-manifest/-/jobs/127610

When we're integrating a single branch into a single manifest branch,
there is no need to run the intgeration pipeline for all configured
integrations, but only for those that match the target branch of the
current merge request.

This should catch an error where during a gitlab-ci merge process the
wrong foo branch is integrated into the manifest, which happened in
Yocto.

We need to pass the correct target branch to the merge request creation
instead of using the project's default branch.

Otherwise no pipeline is created at all in these merge requests, which
prevents the MR from being merged.

We have deleted the original project due to git corruption. Replace with
the new project's ID.

Instead of getting the projects from the manifest file, search them via
their INTEGRATION variable.

Improve log messages on this occasion: print URL instead of just IDs.

Add different integration jobs for different manifest branches. The
merge stage only has one job for each manifest, though, because
otherwise we cannot guarantee a consistent state for all branches.

Extend the deploy script for this purpose, so that it can deploy to
multiple manifest branches at once.

We were passing the complete TemporaryDirectory object to the repo clone
function instead of just the path string, resulting in the repo being
cloned into a local dir "<TemporaryDirectory '/tmp/tmphwakypf8'>".

Fix this to actually use the generated temp dir.

This change makes it necessary to keep the TemporaryDirectory object
reference until we don't need the directory anymore, otherwise it will
be removed immediately.

Get targets dynamically using the INTEGRATION variable instead.

This makes it possible to retrigger jobs that are not part of the
given pipeline but in any nested child pipeline of it.

MANIFEST_PROJECT, MASTER_BRANCH_MANIFEST, MASTER_BRANCH_PROJECT

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