Define & document release process & branching strategies

We may refine this further. Just capturing some things we've discussed internally for now. We'll address this before / as-part-of the next release of the adapter.

Some suggestions for starters:
1. Start cutting release branches — fork a release timestream off main instead of releasing straight from main's tip.
2. Restrict the promotion release Semaphore job to only run from release branches (currently it can apparently run from anywhere). Can also probably make it auto-run when noticing that this commit in a release branch also has a new tag assigned?
3. Also have the promotion process when noticiing release-tag applied and also in a release branch, to also make a github release from that tag.

So, end result:
* When we do the very first creation of a release branch, the promotions probably won't fire 'cause not also tagged since we will probably cut the release branch _prior_ to actually making the release.
* Then after final prep, verification, and changeloggery complete, then someone makes a child of the release branch, makes a release-stamp tag on it, then raises a subsequent PR going into the release branch.
* Boom, automation kicks in and publishes to by pypi and github releases.

TODO:
- Make sure we have the appropriate checks as blockers for merge.

The issue names no files or tests; start by locating the current Semaphore promotion job and the existing release, tag, and branch configuration. Compare that workflow with the proposed release-branch process, then define the documentation and merge-blocking checks needed for tagged release branches to publish to PyPI and GitHub Releases.

Written by the indexing model from the issue text.