Move SuperPMI replay pipeline to "public"

[BruceForstall]

An Azure DevOps pipeline was created to run a SuperPMI replay across all existing public collections when a JIT change is committed (#52392, #56871). This pipeline was created in the "internal" part of the AzDO instance, so is inaccessible to external contributors, and is not triggerable on GitHub pull requests.

This issue tracks the work to move the pipeline to the "public" instance.

Tagging subscribers to this area: @JulieLeeMSFT
See info in area-owners.md if you want to be subscribed.

Issue Details

---

An Azure DevOps pipeline was created to run a SuperPMI replay across all existing public collections when a JIT change is committed (#52392, #56871). This pipeline was created in the "internal" part of the AzDO instance, so is inaccessible to external contributors, and is not triggerable on GitHub pull requests.

This issue tracks the work to move the pipeline to the "public" instance.

Author:	BruceForstall
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	7.0.0

[BruceForstall]

@kunalspathak Are there any other work items tracking follow-up work ideas from the superpmi-replay pipeline creation?

[kunalspathak]

There is no tracking GH issue, but here is what are good to have before we make it public:

• Since I have introduced superpmi-replay** files, we should rename the existing superpmi-collect related files to superpmi-collect* .
• Also, today, if there are JITEE changes, superpmi-collect and superpmi-replay pipeline will start simultaneously. Since there is a reason to do the collection after JITEE changes, superpmi-replay should run on the fresh collection. In order for that to happen, superpmi-replay should not run during JITEE changes, but should be triggered by superpmi-collect pipeline using pipeline triggers mechanism.

[BruceForstall]

I think the "coordinate superpmi-collect and superpmi-replay pipelines after a JIT-EE version change" as a "nice to have", but if it's expensive or complicated to implement, it might not be worth the effort, given the (normally) low rate of JIT-EE version changes.

[kunalspathak]

Done in #60375.