Revisit and standardise tag and release process

# Context
Our current release process (as used in [ANTS v3.2.0](https://github.com/MetOffice/ANTS/releases/tag/v3.2.0), [ancillary-file-science v3.2.0](https://github.com/MetOffice/ancillary-file-science/releases/tag/v3.2.0) for example) involves creating a release branch off main called `vA.B.x`, making some changes related to that release, and tagging a commit on that branch. See for example [v3.2.x](https://github.com/MetOffice/ANTS/tree/v3.2.x).

The motivation for doing the release branch approach was that there are quite a few small changes that need to be made as part of the release. This is mostly hard-coding stuff to the release version, which hopefully we can set dynamically somehow. Additionally, having a release branch lets us make micro releases more easily, by committing to the `vA.B.x` branch and adding a new tag there.

# Problem
We use [setuptools-scm](https://setuptools-scm.readthedocs.io/en/latest/) to dynamically set the version on install of ANTS. This is useful when not working from a tagged commit, as you'd get a version like `3.1.1.dev8+gff5fe287f`. For this to work, the release tag must be reachable from the commit (underlying command is like `git describe --tags`). If the release tag is on a branch off main, then it is not reachable from future commits to main (and subsequent branches off main).

# Proposition
We should consider other options for our tag and release process, in time for the 4.0 release. This should be applied across the following repositories:
- https://github.com/MetOffice/ANTS
- https://github.com/MetOffice/ancillary-file-science
- https://github.com/MetOffice/UG-ANTS
- https://github.com/MetOffice/ug-ancillary-file-science

The desirable features are:
- Simplicity
- Well-documented
- Consistency across repos
- Compatible with setuptools-scm

We should investigate how other projects work.