CI: introduce Cacio

What

This MR introduces Cacio, a library above CIAO. Each component can use this library to define its jobs.

Why

This is part of the "componentification" effort, where each component is a toplevel directory such that once we are in this directory, we should be able to act as if the component was alone in a separate repository. This means, in particular, that components should be able to define their CI in their directory. For Grafazos for instance, this will be done in grafazos/ci. This is already the case, but only partially: jobs are defined in grafazos/ci, but the pipelines themselves are defined in ci/bin/main.ml.

Another motivation for Cacio is that it is an opportunity to introduce higher-level abstractions:

• automatically include dependencies of a job (for instance, for a release pipeline, we only care about the publish jobs; other jobs are merely a consequence, and it is nice to be able to express that);
• automatically compute changes clauses of dependencies (to avoid mistakes where a job would be present but not its dependencies);
• stages are now a sum type (to reflect the efforts of @onurb who is reducing the number of stages);
• job and pipeline names are automatically prefixed by the component's name (for consistency);
• jobs do not carry their rules anymore — instead, Cacio automatically conditions before_merging jobs on changes to the component's paths, and job triggers (manual or auto) are defined at the level of pipelines (so that the same job can be included in multiple pipelines with different triggers);
• components can have their own scheduled pipelines.

This is also the opportunity to rationalize release pipelines: Cacio can define component-specific release pipelines, with some convention on the tag, and with a test pipeline.

How

Cacio uses CIAO (more specifically lib_tezos_ci and lib_gitlab_ci) under the hood. It effectively encodes the jobs and pipelines using lib_tezos_ci. This means that we benefit from the existing work done in CIAO (checks, automatically included Docker image jobs, helper functions…). And it also means that the resulting jobs integrate well with the existing CI. In turn, this means that we can migrate existing components incrementally to Cacio.

Manually testing the MR

make -C ci should compile and have no impact on YAML files.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR