chore: release with ESRP

[Elizabeth Craig (ecraig12345)]

Overview

Update the release pipelines to extend from a new template .devops/templates/release.yml, which takes parameters for common build variants and uses ESRP to release npm packages.

• Each azure-pipelines.*.yml is now a thin wrapper passing target-specific parameters to the release.yml template.
• See release process updates wiki page for more background.
• See ESRP release helper docs for more details about the three-stage pattern and ESRP setup.

This change also prepares the pipelines to move to the Office/ISS project: mainly this involves updating them to extend Office-specific required templates and use a new agent pool.

Notes on pipeline changes

• Some pipelines will run steps that they didn't previously, such as bundle and verify-packaging, but with the nx scoping args those should be no-ops.
• Nightly/experimental bumps' commit and change file messages are slightly less descriptive, but it shouldn't matter since those messages aren't persisted anywhere.
• Disabled v8 website upload since it's very rarely needed and would require a different service connection due to pipeline move. (Though I did update the artifact paths to what would be needed with the new approach of a single outputParentDirectory.)
• Renamed tools.yml to setup.yml and moved branch validation in there (and moved branch/feature variables to variables.yml)

TODO

• update ESRP owners and approvers (it's auto-approved, and the owner only changes who can control it on the ESRP release UI, which is very rarely needed)
• fix post-release tagging in azure-pipelines.release-vnext.yml
• verify post-pack local state (determines correctness of v8 site-manifests--not essential since they're not used, but this was probably why it originally reset to origin/master after the complete publish, since that would have the actual new contents)
• with fetch: false, think about behavior for merge conflicts
  • is there a way to lock against new merges while an official release is running?
• add branch protection rule for experimental/* since it's effectively a production branch (this may cause policy failures in the future)
• can the experimental pipelines be combined to choose the variant at queue time? this would simplify ensuring resource access is set up.
• disable new runs of all uifabric pipelines before merging

[azure-pipelines]

Azure Pipelines:
Some pipeline(s) encountered errors during trigger evaluation.

[github-actions]

📊 Bundle size report

✅ No changes found

[github-actions]

Pull request demo site: URL

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.
Some pipeline(s) encountered errors during trigger evaluation.