We cannot handle build jobs and deploy jobs similarly, because all build
jobs are successful usually, while not all deploy jobs necessarily have
run. Get build.env only from those build job which have a corresponding
successful deploy job, otherwise MACHINE and SUPPORTED_HARDWARE fields
always contain the full list of built platforms, even if they might have
not been deployed.

The Confluence stage is the only stage that needs the MACHINE variable.
Since the collect_release_information script already loads the build.env
from the build jobs, there is no need to store this variable in
deploy.env.

Use a general mechanism of storing all job variables for each build job
separately, so that we have all documentation files in the
FILES_documentation variable. This makes the dedicated HTML_FILES
variable obsolete.
The merged variables are still kept, though, so that we have all
machines in the MACHINE variable to loop over.

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.

Previously the deployed files were stored in a dedicated text file
called files.txt. Move this information to a dotenv variable called
FILES, so that we don't need special handling for it in the Confluence
stage.

This check is not failing anymore since the latest refactorings.

Remove temporary workarounds that were necessary due to changes after
the previously used release kirkstone-7.0.

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.

This variable has been removed in Yocto. Its contents have been merged
into DISTRO_RELEASE_ARTEFACTS.

See for reference:
seco-ne/yocto/layers/meta-seconorth-distro@a316e95e

Extract and save these variables in the build stage instead and
explicitly pass them as arguments to the package script.

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.

The expressions to calculate RELEASE_NAME and RELEASE_VERSION cannot be
stored within these variables themseselves. If set on the trigger level,
they would override the calculated values in build-version.env then,
as trigger variables always have the highest precedence.

Use separate variables RELEASE_VERSION_EXPRESSION and
RELEASE_NAME_EXPRESSION to define how RELEASE_VERSION and RELEASE_NAME
are calculated instead.

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.

The RELEASE_NAME variable can be set directly now, so there's no need to
have a dedicated RELEASE_SUFFIX anymore. A previous configuration like

  RELEASE_SUFFIX: "-custom"

can now be achieved using:

  RELEASE_NAME: "Yocto-${RELEASE_VERSION}-custom"

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.

This had been accidentally removed in
5e36715e.

This was used in times when the same code was executed from different
places. We don't do that anymore, so the variable is obsolete.

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.

Use underscore to separate words within variable name.

FNG_INSTALL_URL was defined in build.env only, and in order to use it
during the build we sourced build.env after writing it.
Remove this workaround and define the variable cleanly in the first
place. This removes the intermediate variable FNG_INSTALL_PATH.
Also move the "/artifact" path from JOB_URL to FNG_INSTALL_URL in order
to make the JOB_URL variable name match better.

On every usage of IMAGEPATH, SDKPATH and LICENSESPATH we prepended
BUILDPATH to it. Prepend it directly on definition to prevent
repetition.
Also remove redundant variable IMAGEBASEPATH.