Support automated releasing of multiple packages from this repo

As part of bringing [@glimmer/component](https://github.com/emberjs/ember.js/pull/20751) 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](https://github.com/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](https://github.com/emberjs/rfcs#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).