Document how is the release process

[humitos]

Merging #16 will make us to do a release of the v1 again. We want to follow what we talked at https://github.com/readthedocs/actions/issues/5#issuecomment-1197688541

This basically means re-tagging v1 to point to the latest commit that includes the single-version option.

Since this release process is no the common for other repositories, we need to document it in a clear way, so it's easy to follow.

[humitos]

The procedure is more or less the following:

• versions are tagged via git using semver v1.0, v1.1, etc
• each major version always point to the latest minor version: in our current case v1 and v1.1 points to exactly the same commit hash
• next time, when we release v1.2, we will need to re-tag v1 to point to that new commit hash
• this is done by deleting the old git tag (git push --delete origin v1) and re-tagging it (git tag v1 <new hash>)
• when a major change is done, we need to tag it as v2 and v2.0
• the release/v<major> branch has to be rebased with the changes from origin/main

[LecrisUT]

* this is done by deleting the old git tag (`git push --delete origin v1`) and re-tagging it (`git tag v1 <new hash>`)

This should be handled by GH workflow, seems rather straightforward to implement with appropriate regex to avoid recursive calls. How about latest tag as well?