Publish to GitHub Packages in addition to npm

[unblee]

WHY

The npm access token this repository publishes with is a granular access token, and those
expire. Every expiry stops the release. Publishing to GitHub Packages as well removes that
dependency for anyone who consumes the packages from there, because the job authenticates
with the GITHUB_TOKEN the workflow already has.

The obvious way to do that is to rename the six packages to the @wantedly scope, which is
what #1146 does. That breaks the consumers. Their lockfiles resolve the unscoped names from
npm today, so a rename means they cannot pick up a new version until they rewrite the name,
and rewriting it points the lockfile at GitHub Packages, which asks for authentication even
for a public package.

So this PR leaves the tree, the lockfile and the published npm names byte-identical to
master, and scopes the manifests inside the release workflow instead, right before the
publish to GitHub Packages. The whole migration is one file.

WHAT

.github/workflows/release.yml only.

• create-release-pr gains an outputs.published line. Nothing else about it changes, so
  the npm publish, the version bump, the tags and the GitHub Release behave exactly as they
  do today.
• A new release-to-github-packages job runs after it, gated on
  needs.create-release-pr.outputs.published == 'true', so it only fires on an actual
  release and only once npm has already succeeded.

The new job rewrites three fields in each packages/*/package.json with jq before
publishing:

field	why
name	GitHub Packages requires the owner scope
publishConfig.registry	points the publish at npm.pkg.github.com
repository	GitHub Packages links a package to a repository through this field, and requires the https://github.com/<owner>/<repo>.git form. The current value is a tree/master/packages/<name> URL, which does not match. repository.directory keeps the subdirectory information that URL carried

dependencies is deliberately left alone. The sources require each other by the unscoped
names, so rewriting the dependency ranges would mean rewriting the sources, the build output
and the snapshots too. Leaving them means @wantedly/frolint on GitHub Packages resolves its
internal dependencies from npm — all six are public there, so they resolve.

publishConfig.access is left alone as well. It does not decide visibility on GitHub
Packages; a package's first publish is private regardless, and the visibility is changed from
the package settings page afterwards.

The commit the job makes exists only inside the runner — lerna publish refuses to run from
a dirty tree. It is never pushed.

Notes for the reviewer

• The base is ci: Update GitHub Actions to latest major versions #1148. release.yml here is written against the post-ci: Update GitHub Actions to latest major versions #1148 shape (@v7,
  Node 20.x, no lerna bootstrap), and the base retargets to master once ci: Update GitHub Actions to latest major versions #1148 merges.
• --no-verify-access is needed because the root devDependencies pin lerna at ^4.0.0.
  It can go once lerna is above 5.2.0.
• The publish path only runs on master, so none of this is exercised by the CI on this PR.
  The first release after the merge is the real test. If the new job fails, npm has already
  published by then, so nothing stops shipping and it can be fixed forward.
• After the first successful publish the six packages land as private on GitHub Packages and
  have to be switched to public by hand, to match how they are published on npm.

[KosukeTakahashi0410]

LGTM
ありがとうございます 🙇🏻