[python-qemu-qmp MR #8] Add git-based package versions, publishing scripts, and dev package builds

[GitLab Bot]

Author: John Snow - https://gitlab.com/jsnow
Merge Request: 
https://gitlab.com/qemu-project/python-qemu-qmp/-/merge_requests/8
... from: jsnow/python-qemu-qmp:packaging
... into: qemu-project/python-qemu-qmp:main

This is all about streamlining the process of tagging, building, and 
publishing. The script authored here, `publish.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 
765e2e210dcbf975f93d1b142761651e61772da6 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

---

This is an automated message. This bot will only relay the creation of new merge
requests and will not relay review comments, new revisions, or concluded merges.
Please follow the GitLab link to participate in review.