determine branching and releasing strategy

Currently rez follows a simplistic branch/release process:
* Changes are merged into master via PR;
* Releases are performed from master;
* Releases follow semantic versioning.

Pros:
* It's easy to track down regressions, since one release typically pulls in a small number of updates (and often a single PR).
* It's simple

Cons:
* It doesn't guarantee stable releases. Many releases have known issues that later releases have fixed.
* Does not convey a sense of which release should be used to the community

Questions:
* What strategy would be better, and why?
* What does the ASWF recommend/prefer, or do they have anything to say about this? Should they?
* Is there existing tooling we can use to support our chosen strategy? (Specifically, to automate as much as possible, and to guarantee well structured changelog and corresponding github release notes).

Review the current master-based merge and release process described in the issue, then investigate ASWF guidance and existing tooling for automated releases, changelogs, and GitHub release notes. Done means the project has an agreed branching and release strategy with a documented rationale and a clear automation plan.

Written by the indexing model from the issue text.