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.

Use underscore to separate words within variable name.

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

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.

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.

The variables CI_PARAM_IMAGE, CI_PARAM_DISTRO, CI_MACHINE have been
defined outside the job in the '.gitlab-ci.yml' file. This has a lower
precedence then variables defined inside the job, but it seems that
these variables are used in the scope of 'Trigger variables' when
available in the trigger job. These override the value set in the
template. As main results this made FNGSystem jobs build the normal
yocto.

Combine all common yaml parts in manifest-pipeline.yml and add
manifest-pipeline-yocto.yml and manifest-pipeline-ci-test.yml
containing the different variable assignments for each environment.

This change implicitly introduces parent-child build job generation in
the ci-test pipeline, like it is done in the yocto pipeline already.
The ci-test build jobs have been moved to build-jobs-ci-test.jinja2
accordingly.

Furthermore rename GITLAB_CI_CURRENT_REV to GITLAB_CI_REVISION and
remove the run conditions from all generated build jobs, since these are
already present in the upstream trigger job.

The repos including these files have to be updated with the new file
and variable names.