Move Docker image building from Jenkins to GitLab CI

Instead of building all images individually, try and build Apertis-based ones from the same common ground. First create a fairly basic Apertis ospack with a few development tools in, then create a Docker image out of it and layer things on top of it.

This unifies the previously separate overlays for the package builder and the package source builder, only keeping the real differences in their respective overlays.

We opt to not use Docker proper since it requires non-trivial Docker-in-Docker setup. Makisu, which could be used as an alternative, unfortunately, has buggy implementation of the ADD command, leaving us the only option to use Kaniko.

The docker building step is templated in .gitlab-ci.yml to avoid repetition. The Debian-based images don’t normally have to depend on the rootfs building step, but to be able to run them asynchronously in the same pipeline stage we need to declare the dependency anyway, as GitLab CI does not currently support empty needs lists.

The branches named apertis/* build their respective Apertis releases, everything else builds the default defined in the CI YAML file.

The jobs for apertis/* branches tag their build images as latest, every other job uses the branch name.

There is also an alternative (commented out) algorithm for getting the tag: if the branch matches the RELEASE variable (sans apertis/ prefix), it is tagged latest, otherwise the branch name. This would imply a workflow involving patching the RELEASE variable value in the pipeline each time we branch. (removed due to the lack of objections to the current implementation)

For robustness, the debos rootfs step uses a stable v2020 image builder step instead of the currently built one.