We do not use Alphaplan anymore. Remove everything Alphaplan related
stuff from the pipeline.

Since the implementation of multiple child pipelines we cannot use the
previous artifacts download links anymore specifying tag and job name,
because the jobs for image build and SDK build are equal. Use direct
download links instead via job number.

This disables the documentation jobs for SDK and FNGSystem.

Previously the documentation files were rendered as part of the package
jobs. Each package job converted the same set of static markdown files
to HTML files, which was redundant.

Add dedicated jobs to build, package and deploy the documentation files.

Modify convert_md2html.py to support file globs as arguments.

This reflects the stage order in the code.

This is a preparation for adding dedicated documentation jobs. In order
to have these grouped by stage along with their corresponding machine
jobs, we have to get rid of the giant outer loop and add loops for each
stage instead.

The "&&" operator does not work as expected when checking if multiple
variables are set.

See for reference:
https://gitlab.com/gitlab-org/gitlab/-/issues/321371

This makes the variable HIDE_FTP_UPLOAD_STAGE obsolete, because we can
hide the FTP stage now by setting DEPLOY_FTP_TARGET to an empty string.

Append it to the configured target at the deploy class level instead.
This removes the need for eval'ing the variables before usage.
RELEASE_NAME can be used directly at the class level because it is known
from build-version.env.

This makes the deploy behavior identical to the Azure stage.

Instead of passing MACHINE from stage to stage or loading it from
testdata.json, use the original value from the Jinja2 loop and set it
directly for each job where it is used.

Instead of passing these variables from stage to stage or regenerating
their values in later stages, use the ones set in the build-version job
at all places.

This adds a machine-independent job "build-version" which populates the
RELEASE_VERSION and RELEASE_NAME variables, so that following jobs can
use these without depending on the various build jobs.
The variables can be set from the trigger job in a project's
`.gitlab-ci.yml` file. They are eval'ed before saving them to
version.env, so we can use deferred variable expansion or even command
execution to construct their values. This mechanism is already used for
the Flash-N-Go System variables.

Rename variable in order to avoid confusion with the original MACHINE
variable used everywhere else. Also rename the local Jinja2 variable to
include an underscore to make naming consistent.

There is no need to add a prefix to the variables. Basically every
variable can be set or overridden at the trigger level, so we just use
plain variable names for everything.

We were using different variable names for the same variable in build
and package stages. Unify these names in order to reduce potential
confusion.

This stage contains jobs to deploy packaged artifacts to our Azure blob
storage. The required variables `AZURE_STORAGE_ACCOUNT` and
`AZURE_STORAGE_SAS_TOKEN` are stored in the GitLab CI/CD variables.
The storage container `AZURE_CONTAINER_NAME` and artifact path
`AZURE_TARGET_FOLDER` are passed from the parent pipeline.

This adds two jobs to the Yocto pipeline:

 - generate-confluence-page
 - publish-confluence-page

The first one generates a confluence page from a template
(`confluence-page.xml.jinja2`) using information downloaded from all
successful "Deploy FTP" jobs of the same pipeline.

The second one publishes this page in Confluence and displays a link to
the new page. If the page already exists it is overwritten.

The place in Confluence where the new page is published is configurable
via the `CONFLUENCE_SPACE` and `CONFLUENCE_PARENT_ID` variables.

Instead of mixing dedicated CI test jobs and Yocto build simulation jobs
within one pipeline, use the new multi-build-pipelines architecture to
split them up into separate child pipelines.
This also makes most of the Yocto pipeline code reusable, so that we
don't have to declare all the jobs again in ci-test.

Instead of building the Yocto image, the Yocto SDK and the FNGSystem
image in one single pipeline, separate them into three independent
pipelines that are triggered in parallel.

This makes the concept more modular: we have a single general pipeline
now which is configurable from outside via variables. Hence we can have
a custom number of pipelines along with custom build targets in each
project without having to make code changes in the gitlab-ci project.

The default Yocto manifest pipeline configures three build pipelines:

- yocto-build-jobs
- sdk-build-jobs
- fngsystem-build-jobs

In a project including the Yocto manifest pipeline, we can disable
certain build pipelines using job rules, e.g. disabling the SDK build:

sdk-build-jobs:
  rules:
    - when: never

Furthermore we can add more pipelines by simply adding jobs extending
the '.build-jobs' class in the project's .gitlab-ci.yml:

yocto-custom-build-jobs:
  extends:
    - .build-jobs
  variables:
    BITBAKE_TASK: build
    CI_PARAM_IMAGE: custom-image
    CI_PARAM_DISTRO: custom-distro
    PACKAGE_TYPE: image

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.

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.

MANIFEST_PROJECT, MASTER_BRANCH_MANIFEST, MASTER_BRANCH_PROJECT

The images from the build job can be directly installed from gitlab.
To achive this some changes in the complete pipeline have been needed.

1. The variables used in the build job, like CI_PARAM_IMAGE, ... and
   related variables like BUILDPATH are only valid in the build job now.
2. The build job writes every variable needed in a follow up job into
   build.env. This also includes the url to the fng-install.sh of the
   final image.
3. The build.env file is used as dotenv artifact, as well as normal
   file artifact.
   The dotenv make the written variables automatically available in
   follow up jobs, that are using the aritfacts, like the deploy job.
   The normal file artifact is available via artifact download.
   (I did't found a way to download the dotenv file instead)
4. Some scripts have been added:
   - Find a job inside the pipeline by name, as the id is not known in
     advance.
   - Download all artifacts or one file of the artifacts from a given
     job
   - Download one file of the latest job by name
5. The scripts are used to download the build.env into the test job
   (where not artifacts are needed anymore)
6. The script is sourced and all variables are available inside the
   script.

Additionally this adds a fake build job to the ci-test pipeline, that
copies an image from srv73 and stores it as artifact in a way that a
test-job can run on it, like in the normal yocto pipeline.

This shares YAML code for the following procedures:
- Build environment
- Source code checkout via repo
- SSH key and known hosts setup
- LAVA test submission
- Docker check if build folder is empty