Configure Semantic Release

[kalzoo]

If we use Semantic Release to release this repository, we'll get automatically-incremented releases, version tags, and changelogs on each merge to master, at the low cost of having to follow a commit prefix convention. This takes minimal configuration:

• a semantic release config (in package.json)
• a couple of lines in the release CI task to dispatch SemRel and possibly access to the credentials it needs to commit tags back to the repo
• [optional] a dry-run task in PR pipelines to show committers what to expect on merge

We also have the option, which I'd recommend, of using their rc branch pattern:

• all PRs target the rc branch, not master.
• On merge to rc, PRs release a new rc version for the next applicable version. For example, if we were to start following v2.0.0, a PR whose commits trigger a minor release would be tagged v2.1.0rc0.
• Full versions are released simply by merging rc into master - no other chores needed. Then, v2.1.0rc0 would become v2.1.0.

[kalzoo]

I'd like to amend this proposal - the rc branch, in practice, is unintuitive for many and causes problems which need manual resolution.

A better option: publish rc versions automatically on every merge to master; publish full versions using a manually-triggered task, so we choose when to release but don't need to do any more than kick off a task.

[abn]

More a heads up that anything - SemVer in practice is not necessarily always compatible with PEP440.