Simplified CI

This MR simplifies how the CI pipeline is defined by using a matrix of parallel trigger jobs, and also adds JUnit reporting to take advantage of Gitlab's test report UI.

This MR also updates CI to use a new version matrix:

• Elixir: 1.12.3, 1.13.4, 1.14.0
• Erlang: 23.3.4.17, 24.3.4.4, 25.0.4
• Alpine: 3.16.1, 3.16.2

Here's an overview of how the CI changes work:

• The build happens in 5 stages: deps, build, lint, test, and docs
• Each stage is run with every valid combination of variables from the version matrix above
  • Currently, this comes out to 8 variants of each stage
  • Some combinations are invalid, and are not run:
    • OTP 25 is not compatible with Elixir 1.12
    • OTP 24 and 25 run on an Alpine 3.16.1 image
    • OTP 23 runs on an Alpine 3.16.2 image
  • Currently this is figured out manually, but in the future the Docker API will be used
• The images for each build are pulled via the Gitlab dependency proxy for the commune_bot group
• The deps stage fetches dependencies for the project and saves them to a cache shared with all runners
  • The cache key is based on the elixir and OTP version, as well as the current branch or tag, like this: deps-ex1.12.3-er23.3.4.17-ci-testing-non_protected
• The build stage pulls in the cached deps and builds the project, saving the result in another cache
  • This cache key uses the same strategy as above
• The lint stage has 4 parts: credo, format, dialyzer, and lint_bash
• credo and format each pull in the build and deps caches, and run their specific checks on the project
• The dialyzer step pulls in the build and deps cache, as well as a PLT cache from previous dialyzer jobs
  • The PLT cache key is only based on the Elixir and OTP versions, so it can be shared across branches
• The lint_bash runs shellcheck against all the bash scripts in the repo
  • This job does not use the version matrix, since it only needs to run once
• The test stage pulls in the build and deps caches, and runs the project's tests
  • A junit test formatter produces a test report which is uploaded as an artifact
  • This allows test results to be visible in pipeline and MR views on Gitlab
• Finally, the docs stage triggers a downstream pipeline which rebuilds the documentation viewable here