Add manual versioned PyPI publishing and GitHub releases

[zasexton]

This extends the packaging workflow in PR SimVascular#248 with explicitly selected releases. Running the workflow requires choosing TestPyPI (the default) or PyPI and a major or minor version increment. Successful production publication then records the package version, tag, and GitHub release.

Changes

• Add release_version.py to calculate the next version from pyproject.toml, apply it consistently to source distributions and wheels, and check package metadata and published file hashes. Expose the packaged version through pysvzerod.__version__.
• Publish through OIDC Trusted Publishing. Require the default branch for production releases; TestPyPI uploads leave the repository version and release tags unchanged. Tag pushes no longer trigger publication.
• Add record_release.sh to commit the published version and push its tag atomically using the release GitHub App, with the commit attributed to github-actions[bot]. Create the GitHub release afterward with generated notes and the published distributions attached.
• Pin all jobs to the selected source commit, serialize releases per index, and validate every distribution before upload. Support retries using the same artifacts, reject conflicting hashes, and recover empty assets left by interrupted GitHub release uploads.
• Add native Linux ARM wheel builds, honor CMAKE_BUILD_PARALLEL_LEVEL, and include the existing steady-flow calibration test in installed-wheel checks.
• Simplify PYPI_RELEASE.md to explain running the configured workflow and recovering failed releases.

[ncdorn]

I was at first confused why the default publishing was testpypi but after reading the docs I understand why this was done. lgtm