Proper changelogs and communicating breaking changes

[vswarte]

Currently I'm just pushing releases whenever I feel like it without a note of what we're breaking or even adding.

A few things off the top of my head:

• Start tagging versions with git
  • Go over diff between tagged versions (commit message quality has to be on-par).
  • Compose an actual changelog (maybe something automated?)
• As long as we're experimenting with how to represent some patterns properly we should remain in 0.x.x so semver does not really apply for the time being (once it does we should examine material such as https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md and go over some rationale about breaking vs non-breaking etc).
• Start using deprecation notices one or two month in advance (preferably some time frame not some amount of versions as we might have moments where we burn through versions).

cc @FeeeeK

[vswarte]

I've started tagging releases starting with 0.7.0 so we can a clean diff for 0.8.0 to base our changelog off of. The 0.7.0 required me to manually figure out what the prev release actually shipped with already 😭