Improve changelog

[GlenNicholls]

I've been finding it somewhat painful to read the changelog as it contains a lot of dev-only information that clutters the space for things I actually care about from a user perspective. The commit logs, issues, and so on are public so I don't see a reason to put internally facing changes in the release notes. In 4.6 for example, I've highlighted a few entries that I consider irrelevant to most people:

Add Python 3.9 and 3.10 to classifiers.

x Use MAJOR and MINOR constants to check supported Python version. [#724](https://github.com/VUnit/vunit/issues/724/)

x Fix pylint issues.

x Use f-strings for string formatting. [#743](https://github.com/VUnit/vunit/issues/743/) [#747](https://github.com/VUnit/vunit/issues/747/)

x Specify encoding when using ‘open’. [#748](https://github.com/VUnit/vunit/issues/748/)

x Set black line-length to 120 characters. [#736](https://github.com/VUnit/vunit/issues/736/)

x Use Path from pathlib, instead of open().

Add support for log location based on VHDL-2019 call paths. [#729](https://github.com/VUnit/vunit/issues/729/)

GHDL supports VHDL package generics. [#753](https://github.com/VUnit/vunit/issues/753/)

Bump OSVVM to 2021.09.

x [Tox] Use pytest for collecting coverage, add py310.
...

I use towncrier which automates the annoyingness of a changelog. If this is of interest, I'm happy to submit a PR, but Tox and some other projects that use it are good examples as well. I recommended that since I see a lot of [Tox], [UG], etc. In those cases, it'd be nice to just have sections like deprecations, features, breaking, docs, etc. Everything that isn't user-facing seems appropriate to put in miscellaneous section if it's notable to some users. Fix pylint issues along with many others above, for example, are not notable IMO as they're more commit messages than release notes.

[LarsAsplund]

Yes, we haven't put any effort into this but from previous experiences with inhouse solutions I prefer a solution where the clarity of the release notes is based on clarity of commit messages and pull requests. To achieve that we should work more on templates. Please go ahead with a PR on this with some examples.

[GlenNicholls]

PR is ready to be reviewed and has examples attached.