feat(release): one v-tag per release, carrying the GitHub release notes

[stefanoverna]

Follow-up to #48, now that the first release on the new tooling (v2.2.7) has
shown what it looks like in practice.

What changed

changeset publish tags every package separately — datocms-plugin-sdk@2.2.7,
datocms-react-ui@2.2.7. That's the right default for independent versioning,
but our two packages are a fixed group: the tags always point at the same
commit and carry the same information, and the vX.Y.Z tag this repo used for
its first 222 tags stopped being created.

So changeset publish now runs with --no-git-tag, and the script creates
vX.Y.Z itself, right after the publish returns.

This doesn't weaken the ordering invariant from #48, it tightens it: a tag can
still only exist for a version that is actually on the registry, and now a
partial publish leaves no tag at all, instead of one tag for each package
that made it through.

GitHub releases

Only 6 of 222 tags ever got a release, and the one recent one (v2.2.1) was
composed by hand. But changesets now writes exactly that prose into the
CHANGELOG.mds, so the script reads each package's section for the version
being released and posts them as one release, one heading per package:

## datocms-plugin-sdk

### Patch Changes

- 5b90e51: Pin the `@datocms/cma-client` and `emoji-regex-xs` dependencies, ...

## datocms-react-ui

### Patch Changes

- Updated dependencies [5b90e51]
  - datocms-plugin-sdk@2.2.7

(That's the real output of the new release_notes helper against the v2.2.7
changelogs.) It's generated, not curated — if a release deserves a write-up like
v2.2.1 got, edit it afterwards.

A prerelease is marked --prerelease, so a publish-next can't take over the
repository's "Latest release" badge.

Preflight

gh and its auth are checked up front, next to npm whoami. A missing GitHub
CLI now stops the release before anything is mutated, rather than after npm has
already been published to.

How this was verified

No release was cut to test this, so here's what was actually checked:

• --no-git-tag suppresses every tag, not just some. Read from the installed
  source: @changesets/cli/dist/publish.mjs:94 guards the tag-only path and
  :188 guards the successful-publish path, both with the same
  options?.gitTag ?? true. With the flag off, gitTagReleases stays empty and
  createGitTags receives nothing.
• The flag parses, and composes with --tag. cac turns --no-git-tag into
  gitTag: false; verified by replaying the CLI's own option declaration
  (--git-tag, default true) through cac with --no-git-tag --tag next.
• The release notes are real. release_notes was run against the actual
  v2.2.7 changelogs — that's the output quoted above.
• gh release create --notes-file - reads stdin (gh release create --help).
• Preflight still aborts off master.

Not verified: the gh release create call itself has never run. The first
release on this script will be the first time it executes.