rustyphoenixcommitrelease 1.1.0

Generates the changelog with git-cliff and commits/tags/pushes a Phoenix release
# RustyPhoenixCommitRelease

`phoenix_commit_release` updates the changelog with [git-cliff](https://git-cliff.org/) and
commits, tags and pushes a Phoenix release, replacing the hand-rolled shell script previously
used in the `commit-release` CI component of [phoenixcitoolkit](https://gitlab.in2p3.fr/CTA-LAPP/PHOENIX_LIBS2/citoolkit/phoenixcitoolkit).
Release-notes generation (the GitLab Release description) is handled separately, outside this tool.

It expects `git` and `git-cliff` to be available on `PATH`, and a `cliff.toml` at the root of
the target repository (git-cliff is run from `--repo-path`, so it picks up the project's own
config).

## Usage

```sh
phoenix_commit_release \
  --repo-path "$CI_PROJECT_DIR" \
  --version "$REPLACE_VERSION" \
  --current-version "$CURRENT_VERSION" \
  --server-host "$CI_SERVER_HOST" \
  --project-path "$CI_PROJECT_PATH" \
  --branch "$CI_COMMIT_BRANCH" \
  --extra-files "Cargo.toml Cargo.lock"
```

`GITLAB_TOKEN` or `GL_TOKEN` must be set in the environment (same convention as
`@semantic-release/gitlab`); it is never accepted as a CLI argument so it does not leak through
the process list or job logs.

Steps performed:
1. `git config --global --add safe.directory <repo-path>` (the image runs as a non-root user,
   the checkout may be owned by another one).
2. `git-cliff --unreleased --tag <version> --prepend <changelog-path>`, creating the changelog
   file first if this is the project's first release (git-cliff's `--prepend` requires it to
   already exist).
3. Rewrites the `origin` remote to an authenticated HTTPS URL built from `--server-host` /
   `--project-path` and the token.
4. `git add`s `pixi.toml`, `codemeta.json`, the changelog and every `--extra-files` entry that
   exists on disk, so the same invocation works unmodified for C++/Rust/Python projects.
5. Commits with a fixed bot identity (`Phoenix CI <ci@phoenix.invalid>` by default, overridable
   with `--author-name`/`--author-email`) and pushes it to `--branch`.
6. Tags the commit with `--version` and pushes the tag as a real `git push` (a tag created only
   through the GitLab Releases API does not honor `[skip ci]` on the tagged commit).
7. Writes `--env-output` (`release-commit.env` by default) with `RELEASE_COMMIT_SHA`,
   `REPLACE_VERSION` and `CURRENT_VERSION`, for GitLab's `dotenv` artifact report.