ci(release): introduce new release workflow

[Saadnajmi]

Platforms Impacted

• iOS
• macOS
• win32 (Office)
• windows
• android

Description of changes

This is the first in a series of changes to redo the publish flow for FURN.

The current release uses beachball, which requires a CI workflow (in Azure Pipelines) that on every commit to main:

• Deletes change files and bumps versions in the repo
• Publish to NPM
• Push the version bump back to Github.

This workflow has two main issues:

• Azure Pipelines requires a long lived Github token with write permission to main. This is especially bad as long lived tokens are getting phased out with no auto-rotate tool.
• If the NPM publish succeeds but not the push back to Github (or vice versa), then the repo is left in a bad state and subsequent publishes fail

To fix this, I propose a new workflow, very similar to Changesets as used by rnx-kit, except still using beachball under the hood.

The new workflow is as follows:

• Introduce a new Github Action that mirrors the changeset action: It creates a PR to commit the version bump to git, rather than writing to main
• After the version bump merges, a separate Azure Pipelines workflow (for compliance) still does the NPM publish on every commit, with no changes to the repo.

Developers in FURN still use the familiar change files, but now:

• We no longer need a Github Token as Github Actions can generate one that lives only as long as the workflow run
• NPM publish (the hard, irreversible thing) runs after the git bump (the easy to revert thing). Therefore, if we end up in a bad state, it's much easier to revert a commit and recover. Consequently, NPM will just mirror whatever state the Github repo is in.

Verification

After this merges, I'd expect a PR to be generated.

Pull request checklist

This PR has considered (when applicable):

• Automated Tests
• Documentation and examples
• Keyboard Accessibility
• Voiceover
• Internationalization and Right-to-left Layouts

[JasonVMo]

This is exciting. One things I'd like to see, though I haven't looked deeply enough to see if this accomplishes it, is for the PR to be regenerated if more changes come in. That way we don't get one version bump per change but rather one per publish.

[Saadnajmi]

is for the PR to be regenerated if more changes come in.

There's a check to update the existing PR rather than make a new one. Would love to just use the changesets action because I'm sure I'm just reinventing the wheel in all the ways they already have.