Automate documentation releases

[CasperWA]

Description:

Closes #232.

This implements several CI/CD jobs:

• Deploy documentation for "version" latest (alias master) whenever a push event happens for master.
• Check documentation for API Reference and the landing page has been updated when creating a PR/pushing to master.
• Deploy documentation for newly released version (updating alias stable to point to it) whenever a new release is published.

This also implements a changelog.
The changelog is auto-generated using the github-changelog-generator in the form of the CharMixer GitHub action.

The changelog will only update on new releases.

Furthermore, a special "this release version" changelog is created and appended to the release description.
An example of this can be seen here, where everything above # Changelog is the original release description.

Type of change:

• Bug fix.
• New feature.
• Documentation update.

Checklist:

This checklist can be used as a help for the reviewer.

• Is the code easy to read and understand?
• Are comments for humans to read, not computers to disregard?
• Does a new feature has an accompanying new test (in the CI or unit testing schemes)?
• Has the documentation been updated as necessary?
• Does this close the issue?
• Is the change limited to the issue?
• Are errors handled for all outcomes?
• Does the new feature provide new restrictions on dependencies, and if so is this documented?

Comments:

To see the new changelog in the documentation do the following:

$ git fetch origin && git branch cwa/close-232-automate-docs-releases origin/cwa/close-232-automate-docs-releases
$ git checkout cwa/close-232-automate-docs-releases
$ pip install -U -e .[docs]
$ mkdocs serve
...
INFO     - [...] Serving on http://127.0.0.1:8000/EMMO-python

Then go to http://127.0.0.1:8000/EMMO-python/CHANGELOG to see the changelog.

[CasperWA]

It would be nice to test this automation a bit - perhaps merging it, but commenting out the publication to PyPI (maybe even using TestPyPI instead).
Concerning the documentation that is no problem. A version can be manually deleted after the fact.

After making sure it all works, the workflow should be updated again to its current rendition (publishing to PyPI).

[CasperWA]

Tagged this as BLOCKING as it should be merged before more PRs are merged.

[francescalb]

Smart with the changelog, I realise I need to step up on typos :)

[francescalb]

Looks good to me

[CasperWA]

The "Check documentation" CI will fail now, since I added a step to test the build of the documentation using the --strict option (turning warnings into errors), and there are warnings in some of the example files. This is fine for this PR, but should be raised as a bug-issue to be fixed ASAP.