Pin PyTorch release version matrix on ROCm release branches

[ScottTodd]

We currently use release branches like https://github.com/ROCm/pytorch/tree/release/2.13 for both nightly releases and stable ROCm releases (see the full table at https://github.com/ROCm/TheRock/tree/main/external-builds/pytorch#supported-pytorch-versions). We'd like for stable/LTS ROCm releases to branch off from these base branches so we have a fixed point upon which to run rebuilds or take controlled cherry-picks that only affect one ROCm release channel at a time.

(cc @HereThereBeDragons @Melantha-S @pragupta @jithunnair-amd @ethanwee1 @pruthvistony )

Branch naming

We'd like to use release/2.12_rocm7.14, i.e.:

• base pytorch fork branch: release/2.12
• TheRock branch: release/therock-7.14
• ROCm-release-specific pytorch fork branch: release/2.12_rocm7.14

Implementation

Part 1 - branch creation

We can create these branch as part of our existing branch setup that already creates e.g. release/therock-7.14 across TheRock, rocm-libraries, rocm-systems, etc.: https://github.com/ROCm/rockrel/blob/main/scripts/create_release_branch.py . (cc @amd-chiranjeevi )

At the moment we only want these branches for stable and long term support rocm releases, not nightly releases or the newly added BKC release stream.

Part 2 - branch usage

• Option A: Land the changes on main and have code behavior change based on --release-type

  For --release-type=prerelease we can have https://github.com/ROCm/TheRock/blob/main/build_tools/github_actions/configure_pytorch_release_matrix.py append the _rocm{MAJOR}.{MINOR} branch naming to e.g. release/2.12.

• Option B: Land the changes each time on the release branch

  Hardcode the expected versions via a commit directly on the release branch (less error-prone but more effort each release)

Part 3 - cherry-pick process

We can reuse our existing cherry-pick process for release branches. We should set up branch protection rulesets for these new branches similar to what we already have for ROCm release branches in TheRock, rocm-libraries, etc. (cc @astyrrian1 )

Other considerations

We may want to do something similar for JAX (cc @erman-gurses @gulsumgudukbay @mminutoli )