* Insert 'imx8' string in the path instead of the specific processor
  type.

* Since custom projects may require to insert some flags in the
  'conf/local.conf' file (e.g. software products commercial licences)
we define the handling of the CUSTOM_CONF variable to contain the lines
that need to be inserted in the file.
* Update documentation accordingly.

In the upgrade from GitLab release 15.4.2 to GitLab release 16.8.2 this
syntax fix is necessary in order for all the integration pipelines to start
correctly

* This modification is necessary in order to use specific runners
  installed on a server dedicated to Edgehog build

* Add E09 board based on Rockchip rk3568 processor
* Add Alder Lake for x86 Intel processors
* Include specific processor type on PROCESSOR variable for imx8 based
  boards

* The build is always triggered via a parent pipeline in this version
of the CI/CD so it was necessary to fix the condition.

* This is a first implementation of automatic testing of Things distro
using SECO LAVA lab.
* The test is directed to 4 device types, one for each main architecture
(imx6, imx8, Rockchip, Intel).

The variable needs to be added as a project variable in order to specify
the manifest file on which the meta-layer needs to be integrated.

The MACHINE parameter is fundamental in order to match the path of the
built artifacts gin GitLab CI

* In a first implementation of the build logic, the downloads and
sstate-cache were supposed to be used only on sheduled and MR builds.
However, as the number of supported boards increase, there is more necessity of
CPU and time to get all Yocto images built when a tag is performed. For
this reason we decide to remove the differentiation at least as long as
the build server is not upgraded.

* The report creation included an extra string on the link to the
artifacts that was not really present and gave rise to not working URLs.

In the previous implementation the deploy-ci job was looking only for
projects with the INTEGRATION project variable explicitly referring to
the manifest repository. With this fix, the script will allow searching
also forprojects with the reference to the meta-layer inside the
INTEGRATION variable, thus allowing to integrate CI also for 'bsp' group
projects.

Every time a BSP related MR is merged, the SRCREV.conf file in the
corresponding meta-layer is updated and all other integration MRs in
that meta-layer can no longer be merged due to conflicts. For this
reason we add this steps every time a BSP related MR is merged:
* Search for all open MRs in the same BSP group of the project on which
the MR occurred.
* Retrigger the pipelines for all these MRs, that in turn updates the
integration branches in the meta-layer.
* All the integration MRs in the meta-layer are now mergeable so that if
two or more MRs are merged (tipically U-Boot and Kernel MRs are merged
almost at the same time) no conflict are expected to occur.
* Moreover, this procedure allows to have an integration MR in the
meta-layer always updated with the latest BSP version in the main
branch.

To make this work we also need to change the retrigger job, avoiding the
possibility to run 'check' jobs that are already running and that would
throw an error.

* The timeout in that jobs need to scale up as the number of boards and
thus build jobs increases.
* Increase timeout also in .infrastructure generic job for CI tasks
since sometimes it failed because it took too much to clone/fetch the
repository.

In the current implementation of Edgehog project, manifest
repositories do not have to contain SRCREV.conf files which are
instead in the conf/SRCREV.conf file of the meta-layer. For this reason
we want to avoid to throw an error when the file is not found
inside the manifest.

* Since the number of custom projects and thus of GitLab groups and
repositories to which the CI/CD steps need to be deployed, jinja2
rendering is introduced in the same way as it was done for the manifest
integration steps.
* Define the INTEGRATION_CI project variable for this repository in
order to define a list of group, manifest repository and branch name to
which the gitlab-ci shall be integrated.
* Use the mechanism of dynamic child pipeline creation.
* Update documentation according to the modifications.

* Insert new section describing all the necessary steps and settings to
include a new project in the CI/CD integration flow
* Insert description of dynamic child pipelines creation for manifest
pipeline
* Insert instructions on how to deploy the GitLabCI to custom projects

These changes are necessary since the mani manifest pipeline is
triggered from a parent pipeline and the rules need to be adapted
according to this.

* Change name of DEFCONFIG_FILE and BUILD_DIRECTORY variables in order to
allow compatibility of the CI/CD also for custom projects
* Insert graphic backend information in the IMAGE_NAME variable
* Fix onvarible assignment for layers integration

* Inserting these rules allow to retrigger pipelines in MR in case some
of the jobs failed
* Insert yamllint control also on masifest pipeline
* Remove some debug echos
* Minor bug fix

* As of now no control were performed over yaml syntax and some fixes
were necessary.
* Increase yaml file line length max value to 200

* The cancel-previous-pipeline job aims at reducing dead time. Indeed,
everytime we push a new commit to a branch, a new pipeline is created.
Often the pipeline for the previous commit has not finished yet, and
GitLab does not automatically cancel it. It consumes valuable build
time, even if we don't need the results anymore. This adds a MR pipeline
job to search for previous pipelines on the same branch and cancel
them explicitly.
* Add yamllint job allowing to check for correct yaml syntax in the
dynamic child pipeline created in the layers and manifest integration
jobs.
* Add yamllint job also on .gitlab-ci pipeline.

This commit introduces major changes in the layers integration steps
performed every time a new MR is opened in one of the BSP repositories.
More in detail:

* Introduces jinja2 templating tool to perform dynamic child pipeline
and dinamically assign the INTEGRATION variable value to the CI jobs.
* The main layers-integration.yml file only contains check and trigger
pipelines to create a dynamic downstream pipeline.
* Introduces layers-integration-jobs.yml that is dinamically assigned
with the variables from the INTEGRATION variable and that executes all
the main tasks of layer integration pipelines

The ideas behind this refactoring are the following:

* Introduce dynamic child pipelines also for pipeline running on the
manifest. This in particular allows to dynamically creates a .yml
configuration file containing all the board jobs via jinja2 templating
tool. With this approach it will only be necessary to define three main
variables in the manifest or in the CI/CD variables of the manifest
repository:
	* MACHINES: a list of the machines of which the build is
necessacy
	* DISTRO: a list of the Edgehog distros
	* GRAPHIC_BACKEND: a list of the graphic backends supported
* Introduce a generic manifest-pipeline.yml that is used both by the
pipeline on the test and general manifest and that simply generates
the final .yml file doing all manifest CI/CD tasks.
* Introduce a generic build-pipeline.yml file containing only the
definition of the main jobs used in the manifest CI/CD (i.e. build,
deploy, test, changelog, etc.).
* Refactor manifest-pipeline-yocto.yml to simply stores variables and
include the other .yml files thus allowing the other steps to be better
tested in the testing group.

* Delete all the content of the boards/ folder containing the job
configuration files for the different boards. The idea behind it is to
use a dynamic child pipeline from a dinamically created .yml file
(containing all the board jobs), thus simplifying maintenance,
avoiding copy and paste errors and allowing to dinamically define as a
global variable the list of machines to be built/deployed/testes.
* Delete files initially imported from SECO-NE original project and no
longer necessary.

Up to now, the ci-test group repositories were used for sporadic
tests but in the optic of a continuous CI/CD improvement they need
to be treated as 'production' repositories. With this approach,
every time a MR is created in the gitlab-ci repo, the modifications
introduced can be tested in the ci-test group repositories.

* The jinja2 templating is inserted for manifest integration steps
in order to use dynamic child pipelines.
* A new job is generated before the integration actually starts that
create the manifest integration jobs, allowing to correctly use
the INTEGRATION global variable.
* Move manifest-integration-jobs to a dedicated yaml file.

* Insert configuration file for boards based on Intel Tiger Lake boards

* Set the number to 32 and increase number of parallel jobs for the
runner

* Increase the timeout to 4h because of increased overload on CI/CD
pipeline

* Remove c61 config file since not released yet

* Fix on AZURE_PATH variable position

* The configuration file allows to build 3 different RAM
configurations: 2x256M, 4x256M, 4x512M
* Insert preliminary test integration job

* Add configuration file for 928 considering all the supported RAM
configurations
* Insert RAM_CONF parameter than need to be set inside local.conf
file at build time

* Insert configuration file for C61 iMX8MM SBC board
* Insert configuration file for D18 iMX8MP SMARC board
* Insert configuration file for D23 PX30 SBC board
* Use same ssstate-cache folder of C31 SBC for D23 SBC

* Insert the parameter BB_NUMBER_THREADS defining the maximum number of
tasks BitBake should run in parallel at any one time (default set to 64).
* Insert the parameter PARALLEL_MAKE specifying extra options that are
passed to the make command during the compile tasks (default set to 64).