Use GitHub releases

[apetro]

Adding a changelog with release notes for releases ( #60 ) is better than not having release notes. Yay progress.

But on reflection, it's feasible to normalize this product's use of GitHub Releases without changing the every-merge-to-master-is-a-release posture. GitHub Releases are just tags with some nice metadata layered on. Git tags are applicable to any commit any time, they don't have to be automated in the release process.

Not only is this feasible, it's desirable. Consumers of GitHub-hosted projects expect to find releases in the releases. It's just what you do. Developers inspecting git history expect to see tags for the released versions. It's just what you do.

Therefore, let's

1. Backfill tags into the git repository for releases not yet represented with a tag.
2. Backfill GitHub releases for tags that do not yet have an associated release, with release notes harvested from CHANGES.md.
3. Remove the no-longer-necessary CHANGES.md
4. Going forward, soon after each release (say, immediately after merging to master), tag the released commit and glorify that tag as a GitHub release. Document this practice in CONTRIBUTING.md