Frontend branching and release strategy #560

Description

The Open edX release process assumes that a component is pinned into a release by git reference, because historically every component was either deployed from, or built out of, a checkout of itself. A modern frontend is neither. It is published as a versioned package and composed into a site at build time, so cutting a release branch in its repository would produce something nothing deploys from and nothing consumes. The process has no answer yet for how a component like that takes part in a release.

Answering it means settling three things that depend on each other. A repository that publishes packages needs somewhere for unfinished and breaking work to accumulate, kept separate from what its consumers are running. It needs a way to keep supporting the versions consumers are already on after that work moves ahead of them. And a release needs a way to pin such a component, and to keep receiving fixes for it over the release's lifetime, without a branch of its own to point at.

This epic covers deciding all of that, applying the outcome where it changes how releases are assembled, and bringing the frontend repositories that already publish packages onto it. Those repositories were set up before any of this was settled and each made its own choices, so the concepts also need to reach them without disrupting the consumers depending on what they publish today.