build: Update version management scripts and control

[trisyoungs]

This PR addresses a few annoying, old, stale, or niggling issues with version updating in the project. The idea is to harmonise and simplify how we manage versions for releases in the repo and keep them consistent with the website etc. The work here assumes that we want to continue with the current release branching strategy - i.e. separate branches for releases, with patches appended and back-merged into develop.

The changes are:

1. The projectdissolve.com website no longer refers to a specific development version of the code (since only git-cliff knows exactly what it will be) but this simplifies its deployment.
2. The projectdissolve.com website no longer lists all legacy releases, because "who cares really", and it simplifies our CI.
3. We introduce a latest tag which follows the last released version, and makes generating git-cliff change logs and CI version checks nice and easy.
4. Previously the main website was updated from continuous pushes, but this meant we had different versions in different files in order to distinguish the development code from the website release. This is now moved to the release pipeline, making it the authority on the release version presented on the website.
5. We still create a PR on release to merge back in to develop in order to update the version in README.md, but this is all we have to do.
6. The update-release-info action has been renamed to set-latest-release-point. This handles the creation of the README.md-modifying PR mentioned in 5). The PR titles created in this action have been prefixed with "[Latest Release]" so that....
7. A new workflow latest-release-point.yml runs only on develop on push, reacts only to changes on README.md, and only runs if the head commit's title is prefixed with "[Latest Release]". If all those are true then the latest-release-point tag is updated to refer to this commit.

TODO

• Remove explicit setting of Windows iss version and use environment variables instead.
• Modify release build to run changeversion to bump version and check for differences to the current one. If no changes, proceed with build and publish, if only patch version changes then submit PR to bump numbers and fail, and if minor or major changes just fail.
• Modify update-release-info workflow to just focus on README.md, and to push new tag latest-release-point to this commit somehow?
• Modified main continuous workflow to dynamically set code / package version at build time, since we don't know what the new version number will be. This depends on git-cliff being able to trace back to the latest-release-point tag generated by 7).