Publish web-features NPM package

[foolip]

As a follow-up to #9 we should publish web-features to NPM, ideally set up in a similar way to https://github.com/w3c/browser-specs/blob/main/.github/workflows/release-package.yml.

[ddbeck]

Capturing the discussion on #36 here, and adding some useful detail (hopefully):

Description

The workflow desired, in broad outlines:

1. Generate a release branch and PR, automatically bumping the version number and other boilerplate tasks.
2. Maintainers complete and update the release PR until a release is ready to be published (e.g., when sufficient changes or time since last release have accumulated and the release notes are finished).
3. Maintainer merges the release PR.
4. Automatically tag the release, generate release artifacts, and publish the release to npm. 🎉

I've tried to split this up into core requirements and nice-to-have embellishments.

Requirements

• A CLI for running release tasks (e.g., scripts/release.ts, perhaps with some sub commands for the various bits, like init, update, publish, etc.)
• A GitHub Actions workflow to be triggered manually (e.g., via npm run release -- init) that starts a PR for the next release. It must do the following:
  • Branches from main to a release branch with a documented, formulaic branch name
  • Bumps the version number (e.g., ultimately runs npm version patch, probably via the CLI above—commits to the branch but doesn't create a tag at this point)
  • Opens a PR from the release branch
  • Requests review(s) from the release maintainer(s)
• A GitHub Actions workflow to be triggered by merging a release branch into main that publishes the release. It must do the following:
  • Assert that the merge a) is a release branch merge and b) the merge actually bumped the package version number, or exit
  • Tag the release
  • Create release artifact(s)
  • Run npm publish

Other things that would be good to have at some point

• Automatically trigger the generation of the PR for the next release, on a schedule TBD or by some measurable metric, interval, etc.
• On release PR creation:
  • Generate a stub release notes Markdown file for the release maintainer to fill in and complete
  • Provide release how-to documentation as the PR message body (e.g., instructions on how to change from patch to minor or major, how to force a rebase, how to cancel the release, etc.)
• On main changes, automatically rebase the release PR
• On release PR merges:
  • Generate a GitHub release
  • Delete the release branch

[foolip]

It is published...