add release docs to explain branching

[colearendt]

No description provided.

[ianpittwood]

LGTM. We should merge this soon and create the branches if we want this to become the new norm for our next release(s).

[msarahan]

I wrote up this doc for my idea on splitting repos: https://positpbc.atlassian.net/wiki/spaces/ENG/pages/293437505/March+2023+rstudio-docker-products+rework

I also tinkered with the idea at https://github.com/orgs/repo-federation-demo/repositories?type=source

Ultimately, I think it may not work due to requiring PAT, which would require a service account, which I don't think IT wants to do. However, it has given me some ideas on how to blend the stuff in there with our mono-repo here. I will describe that in another issue.

One thing that I think this PR needs is a description of how to update older releases, like the vm2 CVE thing in the 2022.07.0 r-session-complete image. The general idea in my mind is:

• find where the image was updated to the next version.
  • find the version reference file, such as https://github.com/rstudio/rstudio-docker-products/blob/dev/r-session-complete/Justfile
  • look at its history by clicking the "blame" button, and look for the line corresponding to the product version.
  • Click on the link for the commit on the product version line
  • copy the commit id in the upper right
• In your terminal, with a local clone of the rstudio-docker-products repo, git checkout <commit id you copied>~1 - Note the ~1 on the end there. It says "the commit one before this reference"
• create a new branch: git switch -c <new branch name>. The naming standard for old release branches is: <image-name>-<image-version>-x, where the -x indicates that it is a living branch, not a tag.
• Edit the workflows as necessary to remove other products (see dev...r-session-complete-2022.07.0-x for an example)
• Commit the workflows
• Push the branch. Ideally, your images are pushed automatically. If not, you need to revise your workflows

Please revise and add this as you see fit.