Add manually-triggered release/publish workflow (version bump + PyPI)

[jakehadar]

The package on PyPI is stale (still 0.1.8, predates all the Python-version-support and systems.csv work in this repo). Rather than automating PyPI publishes on a schedule (rejected — see discussion on #13, publishing should stay a deliberate, reviewable action, not tied to routine data refreshes), add a manually-triggered GitHub Actions workflow to replace the local python setup.py upload release path.

Proposed design

Trigger: workflow_dispatch with a bump_type input (patch/minor/major, default patch).

Steps:

1. Checkout with full history + tags (versioneer derives the version from git tags; bumpversion needs to read/create them)
2. Run the test suite as a gate — refuse to publish if pytest fails
3. bumpversion <bump_type> — updates .bumpversion.cfg, commits ("Bump version: X -> Y", matching existing commit style), creates the git tag
4. Push that commit + tag back to master
5. Build sdist + wheel (python -m build)
6. Publish to PyPI
7. Create a GitHub Release for the new tag

Open decisions

• PyPI auth: Trusted Publishing/OIDC (no stored secrets, requires one-time setup on the PyPI project's Publishing settings) vs. an API token stored as a GitHub secret (simpler now, but a long-lived credential to manage/rotate).
• Old setup.py upload command: remove now that CI replaces it, or keep as a local fallback.

[jakehadar]

Resolved and validated with a real run. #19 (merged) added the `Release` workflow; ran it manually via `workflow_dispatch` with `bump_type: patch`, and it completed successfully end-to-end:

• Version bumped `0.1.8 -> 0.1.9`, committed and tagged on `master`
• sdist + wheel built and published to PyPI via Trusted Publishing (no stored API token)
• GitHub Release 0.1.9 created

PyPI now has the current Python 3.7-3.14 metadata and the refreshed `systems.csv` data, closing the loop from a stale 0.1.8 package all the way through automated release.