Add a Changelog

[luleyleo]

This introduces an in-tree changelog base on Keep a Changelog.

Whenever a new PR ist created it should contain changelog entries for everything it changes, thus keeping the changelog always in sync with master.

Every changelog entry is annotated with the PR that introduced it and the author for attribution.

The attribution is also the reason why the Maintenance section exists, even though entries in it have no direct impact on users.

Annotating entries with a link to the introducing PR causes a chicken-and-egg problem tho.
When creating the PR you wont know the number yet, which you need to refer to it.
Having a quick link to the related PR seems very useful however as it provides much more information about the change than the changelog ever could.

See Zulip for previous discussion.

[xStrom]

The chicken and egg problem isn't that bad because github issue numbers are sequential and you can guess what number you will get. Sometimes you lose the race, but that should be rare.

[luleyleo]

Right, they are sequential that makes it a bit better but then you would have to figure out what the current count is at, I wonder if there is like a 'next PR number' badge that we could add to the readme for example.

[xStrom]

Generally looks good, thanks for taking this on! I made some inline comments about improvements.

Also do a search & replace for my name: xStorm -> xStrom.

[luleyleo]

@xStrom I've fixed your name (sorry for that), added some other things I've missed and hopefully corrected the tenses.

I'm not sure if we should include changes to internal-but-public API such as InternalEvent. For now I've just added them.

[xStrom]

We should also add a section/note to CONTRIBUTING.md about needing to change the changelog in PRs.

I think documenting the internal stuff is fine while we're in the 0.x versions. We can reconsider this later, e.g. once we hit 1.0.

Also #890 got merged.

[luleyleo]

I've added it to CONTRIBUTING.md.

I've not added anything regarding #890 as it is a follow-up for a feature that is not released yet.
I think keeping the changelog compact and only freezing entries once the version is released makes it easier to read. For example I've merged the Event::MouseLeave addition with your effort to collect InternalEvents. Thus there is only one entry mentioning the addition of InternalEvent::MouseLeave.

[xStrom]

I think that makes sense. We don't want the changelog to be a mirror copy of the merge commit log. Multiple PRs working on the same conceptual feature can be streamlined into a single entry in the changelog.

[xStrom]

For completeness sake, let's add all the previous versions to the changelog as well. I know we don't have the the actual changes for them right now, but we could at least have the version numbers and their dates.

[luleyleo]

I've added them, left out 3.3.3 however as it was yanked anyways.

[cmyr]

This is great, thanks for taking it on!

[xStrom]

Good to go! 🥳