Document the use of pre-release channel

[kingdonb]

I have noticed a few things which I'd like to document about the release process, relating to errors I have made and their effects during the release process!

Number one is that accidentally 0.19.10-edge.0 was published after 0.19.11-edge.0 by about 7 minutes! This was in error, the newer version number should come after the older one, but because of VSCode Extension marketplace strangeness in the way that version numbers are parsed, these numbers were "upgraded" to timestamps by our build process and the right thing happened, the build that was published later became the promoted one and it is what edge channel subscribers get.

I am not sure how this happened because the version numbers are assigned automatically, should have perhaps rebased before publishing from the feature branch, but these version numbers don't actually get used on down the line anyway and this is what I think we basically should add to the developer docs somehow, as I've definitely tripped over this already myself a few times now.

The weirdness is basically as this article describes:

Given that the VS Code Marketplace currently doesn’t support edge release versions, we’ve built a little script that updates the version to something like v1.2.1646405133 in which we replace the patch version number with a timestamp. This ensures that pre-releases will have a higher version than stable ones and that we can continuously make new pre-releases.

https://www.stateful.com/blog/the-github-action-you-need-to-publish-vscode-extensions

This is where we borrowed our release machinery from, these helpful folks have done the research and front-loaded our struggle for us! The release process is easy now, we just have to learn how to wield this pre-release channel most effectively and what to do with version numbers if there's something special that we need to do in that respect.

[kingdonb]

We learned this week that pre-release tags need to be in the main branch history or they do not count. They need to count so that the tag edge.0, edge.1, etc. can be properly incremented. So my practice of pushing pre-releases from a branch which may or may not get merged, maybe should not be used. Instead, merge a PR and push it as a pre-release.

We should investigate how to make a feature available only in the pre-release channel (without creating a separate pre-release trunk, eg. feature flags.)

[kingdonb]

We are testing prereleases for in advance of the new Minor milestone 0.20.0 – we may do one more patch release for 0.19.x before that one lands, but IDK because we've already merged at least one feature (#319) into the main branch, so I think the next release will have to be 0.20.0.