Add git-based package versions, publishing scripts, and dev package builds

This is all about streamlining the process of tagging, building, and publishing. The script authored here, scripts/package.py, is designed to make the publishing process fool-resistant by providing a slew of smoke tests designed to prevent erroneous, premature, or inconsistent releases.

A note:

• Before this is merged, I will want to tag 765e2e21 as "v0.0.0a1" on origin/main so that the dev package build that will be incurred after the merge is accepted will have an appropriate version (v0.0.0a2.devNN+09abcdef). I didn't do it yet so that there can be feedback on this scheme first, in case. I do not want to ever delete a tag from origin/main in keeping with the principle that git commit history should never change.

The intended release process is expected to be something like this:

1. An MR is submitted that updates the README with new changelog info, any last touchups, etc. The MR makes it clear to reviewer(s) that a new version will be published contingent on review, successful pipelines, etc.
2. MR is approved and merged. Pipelines run and pass.
3. A maintainer (me) runs python3 publish.py tag from my local repo and assigns a new version number. The annotated tag is pushed to origin.
4. Maintainer runs python3 publish.py build to create new distribution files on their local machine.
5. Maintainer runs python3 publish.py publish --test as a dry run to push a new package version to test.pypi.org. Maintainer inspects that it appears to have worked correctly (readme looks right, metadata appears to render correctly, etc) and all pieces appear to be in place.
6. Maintainer runs python3 publish.py publish to finalize the submission to PyPI.

The authentication for the publish script is provided by the environment variable TWINE_PASSWORD, which takes the form of a PyPI authorization token. It would also be possible to utilize keyring support, but I didn't leap that far ahead yet.

Each version tag is designed to be signed and annotated. Each distribution file uploaded to PyPI is also designed to be signed. At present I am just using my own personal key, but I could look into creating a generic "QEMU project python release" key for the purpose, if requested. (Please suggest key creation parameters in this case.)

LASTLY, I intend to - after this series is merged - send a followup MR to indicate the v0.0.1 release, and then test the process by tagging and releasing v0.0.1. See milestone %v0.0.1 (First release)

See the commit messages on each change attached here for additional information, notes, musings, poetry, etc.

Closes #16 (closed)