CI-in-OCaml: add [ci/lib_gitlab_ci]

What

This is the first part of the CI-in-OCaml project. It adds the library ci/lib_gitlab_ci. It contains type definitions corresponding to the AST of GitLab CI YAML, smart constructors for values thereof and printers of such values to YAML.

This MR makes no change to the current CI configuration, and is just a stepping stone to the rest of the MRs in the stack.

Stack

1. !11999 (merged) (add ci/lib_gitlab_ci). Look here for rationale. <- You are here
2. !12000 (merged) (add ci/bin)
3. !10948 (merged) (translate .gitlab-ci.yml)
4. !11461 (merged) (translate latest_release pipeline)
5. !11500 (merged) (translate *release_tag(test) pipelines)
6. !11501 (merged) (translate master_branch pipeline)
7. !11534 (closed) (translate schedule_extended_test pipeline)
8. !11671 (closed) (translate before_merging pipeline)

Why

The code has borrowed heavily from romain's previous proposal: https://gitlab.com/nomadic-labs/tezos/-/tree/romain-ci-in-ocaml/ci

To main motivations are to start reducing the technical debt that accumulated in the .gitlab-ci.yml files:

• The nest of templates and extends that have proven impossible to debug
• Inconsistent naming patterns
• A set of rules templates that are hard to compose

My design goals here are to:

• Make something quickly that works, but which we can expand upon incrementally
• Support a "strangler" pattern, were we can keep some files written in .yml until we have the time to rewrite them in OCaml
• Provide some level of safety through types and run-time checks.
• Move away from extends and provide safer mechanisms for rule composition

At the moment, this MR only:

• Adds an AST and printer for a pretty large subset of .gitlab-ci.yml keywords

How

By adding a library to ci/lib_gitlab_ci. This library contains a straight, pretty Octez-agnostic, definition of GitLab CI YAML. It will serve as a low-level layer for the more Octez-specific API in the following MR in the stack.

We've considered adding linters, switching CI system and switching build system. This approach was chosen since it gives the same benefits as linting, while at a smaller development cost and less risk than switching CI or build system.

Manually testing the MR

• dune build ci/lib_gitlab_ci
• Read the MLI files and make sure the documentation makes sense.

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