Image and SDK package jobs call the same package script just with
different arguments. Instead of having two job classes `package_release`
and `package_sdk` for these two tasks, merge them into the base class
`package` and make the differences configurable via a variable
`PACKAGE_TYPE`.

Instead of hard-coding the rules for manual builds in each actual job,
conditionally add this to the `buildbase` class and add a variable
`MANUAL_BUILD` to the according jobs.

Image and SDK builds share a lot of similar code. Instead of having two
job classes `build_yocto_image` and `build_yocto_sdk` for these two
tasks, merge them into the base class `build_yocto` and make the
differences configurable via a variable.

The `dump_install_command` part of the script, which was not executed
for SDK builds, is always present now, but it's only executed if the
`INSTALLSCRIPT` variable is set, which is not the case for SDK builds.

The `collect_srcrevs` part of the script is executed in all cases. It
was not part of the SDK build before, but it's not less relevant there.

Instead of specifying all possible artifacts paths and abusing the fact
that GitLab ignores non-existing paths during artifact upload, implement
a cleaner solution with a configurable path.

This is the first step on the way to a common pipeline for all build
configurations.

IMO code is easier to read without the proposed change:
https://docs.sourcery.ai/Reference/Python/Default-Rules/min-max-identity/

Move the disabled check to the top of the list and add a comment that
all the checks below need to be verified.

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/or-if-exp-identity/

See for reference:
https://docs.sourcery.ai/Reference/Python/Default-Rules/remove-str-from-print/

now() is officially preferred over today() according to the docs.
See for reference:

https://docs.sourcery.ai/Reference/Python/Default-Rules/use-datetime-now-not-today/
https://docs.python.org/3/library/datetime.html#datetime.datetime.now

Disable all checks which do not pass currently. These should be enabled
in the future along with a code refactoring to make them pass.

We had timeouts during the upload of the artifacts
so I increase it to 90 minutes.

Since the changes of 939ade2b we observe
that pipelines are executed on non-protected branches, which is not what
we want.

GitLab's documentation was a bit unclear on the according CI variables
CI_COMMIT_REF_PROTECTED and CI_MERGE_REQUEST_TARGET_BRANCH_PROTECTED, as
stated in this stack overflow answer:
https://stackoverflow.com/a/59023344/3018229

We need to explicitly check for the variable values to be "true" instead
of just checking whether they are set.

Previously we had the master branch hard-coded in a variable in order to
determine whether to run the integration pipeline (on non-master branch)
or the merge pipeline (on master branch). This variable had to be
adapted everytime we copy a branch, which can potentially be forgotten
and lead to problems.

Remove the hard-coded branch and use the branch protection state for
this decision instead in order to make this more flexible.

The rules for the yamllint jobs have been defined in the .yamllint class
before. They were overridden in the manifest pipeline's yamllint job,
though, which has its own rules, so we don't need them to be inherited
in this case. And in the manifest integration pipeline the rules can be
much easier, so define them there instead of at the class-level.

Usually project name and path are identical after project creation. It
is possible, though, to change the name of a project without changing
its path.
When triggering a pipeline on the integration branch, we are using the
CI_PROJECT_NAME variable to reference the project. Unexpectedly, this
variable contains the *path*, not the *name* of the project (see
https://gitlab.com/gitlab-org/gitlab/-/issues/20030).
Hence we have to use the project path in all other places where the
integration branch name is constructed in our Python code.

This will make the manifest project support the "skip build" label.

This reverts commit 4db257d3.

It does not work on the manifest, because we do not run merge request
pipelines there, so CI_MERGE_REQUEST_LABELS is not set at all.

GitLab API has changed:
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/94164/diffs#diff-content-c201dae00b72426693ddcb40edf6005e7702e935

Instead of hard-coding the project list in the changelog generator
script, make them passable via arguments. This way we can have different
changelogs in different envrionments. Hence we're adding the changelog
job in the ci-test environment as well.

This case should trigger a new pipeline instead of reporting an error.

This fixes older releases not appearing in the changelog.