Implement CI bootloader script

[SimeonEhrig]

At the moment, sometimes if I changes something on the CI, I also need to modify the content of .gitlab-ci.yaml in the projects, which uses the CI scripts. At the moment, there are 4 projects, where I need to do the same changes. To remove the need of this redundant work, I want to implement a CI bootloader.

The basic idea of the bootloader is, there are only two jobs defined in the .gitlab-ci.yaml. The first job downloads the CI bootloader and execute it. The bootloader, scans it's environment (environment variables) and creates depending on it a GitLab CI yaml file, which contains the whole test pipeline such as unit and integration tests. The second job simply executes the CI pipeline.

In the best cases, we don't need to change the .gitlab-ci.yaml anymore, if we change the CI scripts. Maybe it is required to set optional variables for single projects. For example we change the default Julia version for integration tests from 1.10 to 1.11 but project X does not support it yet. Therefore it still needs to run with version 1.10 until the problem is solved.

Possible .gitlab-ci.yaml:

stages:
- generate
- run

generate_pipeline:
  image: julia:1.10
  stage: generate
  script:
    - apt update && apt install -y git
    - git clone --depth 1 -b dev https://github.com/QEDjl-project/QuantumElectrodynamics.jl.git /generator
    - julia --project=/generator/.ci/CI -e 'import Pkg; Pkg.instantiate()'
    - julia --project=/generator/.ci/CI bootloader.jl > $CI_PROJECT_DIR/pipeline.yaml
  artifacts:
    paths:
      - pipeline.yaml
    expire_in: 1 week
  interruptible: true
  tags:
    - cpuonly

run_pipeline:
  stage: run
  trigger:
    include:
      - artifact: pipeline.yaml
        job: generate_pipeline
    strategy: depend

[AntonReinhard]

This is definitely a good idea in my opinion and should make maintenance a lot more straightforward and adding new packages simpler.

[SimeonEhrig]

The current implementation contains a lot of code, which needs to be refactored or unified. Nevertheless I want to merge this unclean version to enable easier bug fixes and extensions of the CI.
Refactoring and tests will be implemented in following up PR's.

[SimeonEhrig]

Test PRs are:

• Use CI bootloader QEDbase.jl#135
• Use ci bootloader QEDcore.jl#87
• Use CI bootloader QEDprocesses.jl#112
• Use ci bootloader QEDevents.jl#54
• Use CI bootloader QEDfields.jl#56

[AntonReinhard]

Looks good to me.

Test PRs are:

* [Use CI bootloader QEDbase.jl#135](https://github.com/QEDjl-project/QEDbase.jl/pull/135)

* [Use ci bootloader QEDcore.jl#87](https://github.com/QEDjl-project/QEDcore.jl/pull/87)

* [Use CI bootloader QEDprocesses.jl#112](https://github.com/QEDjl-project/QEDprocesses.jl/pull/112)

* [Use ci bootloader QEDevents.jl#54](https://github.com/QEDjl-project/QEDevents.jl/pull/54)

* [Use CI bootloader QEDfields.jl#56](https://github.com/QEDjl-project/QEDfields.jl/pull/56)

I take it that we can update these to the new dev branch and merge them after this is through?

[SimeonEhrig]

Looks good to me.

Test PRs are:

* [Use CI bootloader QEDbase.jl#135](https://github.com/QEDjl-project/QEDbase.jl/pull/135)

* [Use ci bootloader QEDcore.jl#87](https://github.com/QEDjl-project/QEDcore.jl/pull/87)

* [Use CI bootloader QEDprocesses.jl#112](https://github.com/QEDjl-project/QEDprocesses.jl/pull/112)

* [Use ci bootloader QEDevents.jl#54](https://github.com/QEDjl-project/QEDevents.jl/pull/54)

* [Use CI bootloader QEDfields.jl#56](https://github.com/QEDjl-project/QEDfields.jl/pull/56)

I take it that we can update these to the new dev branch and merge them after this is through?

That's correct. I need only remove the last commit. Than they are ready for merge.