chore: use changesets to support an automatic release process

[zbynekstara]

Description

A simpler version of #3445.

Use changesets for deferred versioning and changelog creation.

NOTE: Tags/Releases become per-package (@joint/core@4.4.0) instead of v4.3.1.

Motivation and Context

This will allow us to streamline our release process by asking PR contributors to make versioning and changelog decisions at PR time (when they have the most context about their changes) instead of at release time.

A changeset is a file inside .changesets/ folder (one per PR), which records two things:

• Which packages need a version bump due to this change, and if it is a patch/minor/major bump.
• What the changelog line(s) for this change should say.

Setup TODO

Before the Changesets release pipeline can run, these steps need to be completed:

• Add NPM_TOKEN to secrets, with publish rights for all eight public packages (we cannot use trusted publishing yet).
• Enable auto-merge (repo "Settings → Actions → General → Allow GitHub Actions to create and approve pull requests"). We may need to change GITHUB_TOKEN settings to make this work.
• Depending on how the master branch protection is setup, we may also need to:
  • Create the release GitHub App + use it in the action - an App with contents: write + pull-requests: write,
    installed on clientIO/joint. Add its credentials as repo secrets RELEASE_APP_ID and
    RELEASE_APP_PRIVATE_KEY.

What to expect on the first run

The empty changeset currently in .changeset/ means the first push to master goes into version mode and opens a "Version Packages" PR whose only content is the deletion of that file — no version bumps. Merge it; select-mode then reports none (every version matches npm, which is exactly what the version/private fixes bought you) and nothing publishes. Real releases start with the next PR that carries a real changeset.