Support automated releasing of multiple packages from this repo

[kategengler]

As part of bringing @glimmer/component into the repo and other possible packages being brought in, we'd like to have an automated way to release multiple packages with appropriate changelogs.

Fortunately, members of our community have already built @embroider-build/release-plan to do such a thing. It is currently used to release from the embroider monorepo.

However, ember-source follows a six-week "release train": there is a stable release roughly every 6 weeks (every 4 versions excluding x.0 is an LTS candidate) and a major release after every x.12 release. New deprecations targeting the next major are not permitted to land after the x.10 release. All public API changes should have an RFC and all features should behind feature flag until the RFC has had a successful the Ready for Release Stage.

Current release process details

• Changes to main are released on every commit to s3 as canary. (automated)
• Weekly, changes on main are released as alpha on npm. (automated)
• At least weekly, a contributor looks for changes from main that are tagged (and appropriate to be backported) to beta, backports, and creates a new beta release if there are changes. In a beta cycle, there can be as few as 1 beta release or theoretically as many as needed, depending on the changes that land.
• At least weekly, a contributor looks for changes on main or beta that should be backported to release or lts, backports if appropriate, and releases if appropriate. If the new lts is the latest lts, they update the tag on npm.
• Every six weeks, the beta branch is "promoted" to release by a contributor creating a new stable release. When the stable release is published, the prior release may be promoted to LTS, if is a successful candidate.
• Every six weeks, the main branch is cut over to beta. Any non-enabled feature flags are disabled on the beta branch. A new beta is released.
• After creating the latest point release, a contributor bumps the version on main. If we've reached the x.12 release this rolls over to the next major.

release-plan is designed to release a monorepo based on PR tagging and SemVer, expecting that when it is time to release any package, it is time to release all the packages. While ember-source follows SemVer, we also tie our releases to calendar time in an atypical way: even if a release contains only bugfixes, we'll release it as a minor version on our cadence. Our majors do not have explicitly PR'd breaking changes (though I suppose we could label a manual version bump a breaking), but only drop deprecations that were already added. We need to determine how release-plan can be made to work with this release cadence or how we can adapt Ember's release process to be more typical.

(Option A) Adopting and adapting release-plan

• Write up a theoretical RELEASE.md
• Update release-plan to support build-provenance (we don't currently have this for ember-source but do need to do it)
• Do we need to move away from cherry-picking and to a merge-based flow?
  • What does this mean when the various branches diverge greatly? (New deprecations added, deprecations removed, feature flags, reorganizations, etc).
• How do we tag LTSes? LTSes are only promoted once the next stable is released.
• Plan for how to release older LTSes, if necessary.
• How do beta and alpha releases work, especially wrt the CHANGELOG? We currently remove betas from the CHANGELOG when they are released as stable. We also remove any entries that were previously in a stable release.
• How to make the CHANGELOG reflect feature flags? We currently leave out PRs from the CHANGELOG from features that are not toggled "on" and then add them (with a reference to the related RFC) only once they are enabled.
• Should we have it create one GitHub release per package? I lean towards yes as various tools read the GitHub releases (including the bot that updates WikiData). Or is there a standard format to use when it includes multiple packages?

(Option B) Updating Ember's release process and adopting release-plan

Release ember-source based on the changes made (minor or patch), as frequently as we care to release. This will require RFCs to update the Major Version Cadence, deprecation-freeze, and LTS policies (my best guess would be to move them to calendar-based instead of n-release based).