[DOC] Branching strategy and transparent release cycle

[rustatian]

Starting from RR 2.0.1 we will try to adopt the following branching strategy with the master as nightly, beta, and stable releases:
https://internals.rust-lang.org/t/release-channels-git-branching-and-the-release-process/1940

From my POV, at the moment, we have our releases in chaos. There is no particular time when the feature will be released. A transparent release process also doesn't exist. Users can't see when we plan to add one or another feature or bugfix. Lack of beta testing leads to weird bugs in runtime, which definitely leads to a bad user experience.

How to solve these problems:

1. New public board https://github.com/orgs/spiral/projects/2 (golang repositories). The community will have the ability to track bug fixes or features implementation. New minor release every mount (2.x.x) and bug fixes as soon as we fixed the urgent bug.
2. The last days before release will be testing days with code freeze. If the beta-testers didn't fully test the feature (or bug), it would not be included in the stable branch.
3. Core team public discussions about the plans for the next release (corrections and notes) will be at the SpiralScout YouTube channel (we will provide the link later).
4. New branching strategy will solve the problem with feature (bug) testing. Currently, we have neither beta nor stable branches to provide enough time to test the feature. After adopting this strategy, we will have the ability to merge tickets with provided unit tests into the nightly. After testing the integration within the beta branch, we will merge the changes into the stable.