Add release workflow, use hatch-vcs for versioning

[dfangl]

Motivation

We need a new plux release, and with changes in ownership and required changes in the future, I expect some more releases to come.
So, this is a good time to introduce a proper release workflow.

Changes

• Add automatic release workflow on tag push:
  • Tags are protected by branch protection rules, only repository admins can push a new tag
  • Releasing uses OIDC to push a new release to pypi - without static credentials (https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-pypi)
  • Release environment can only be used for tag pushes
• Use dynamic versioning based on git tags
  • uses hatch-vcs (the setuptools_scm pendant for hatchling)
  • Since we do not publish dev tags from the pipeline, we do not disable local versioning
  • Since we do a shallow checkout in the regular pipeline, on non-tagged commits, the version will default to 0.1. There should not be any adverse effects currently, but it might be confusing. Should we change this?

Related

Fixes UNC-202

[thrau]

Thanks Daniel for adding this!

Overall this is a solid and modern release setup (tag-driven releases, PyPI OIDC, protected tags/environments), and using hatch-vcs for versioning is a reasonable choice. One concern to keep in mind is that if we start tagging (and thus releasing) on nearly every commit (which we likely will, because we rarely group multiple commits into a release, since the commit velocity is very low on these sort of repos), the history can get noisy over time. This is fine if intentional, but worth being explicit about.

In a conversation, Daniel has stated that he doesn't mind, so 👍 from me.

Something else to consider is that we should start standardizing release processes across OSS projects like these. cc @alexrashed