Add release PR workflow

[inknos]

This is a first step that makes the foundations for future work. Ideally we'd like to create this automatically when podman publishes a release.

At this state, ideally, the workflow will be done in 3 manual steps.

1. Triggering a workflow by specifying a version number. This it will create a PR with all the necessary changes and run all the tests.
2. Manual merge: after that another action will create and push a git tag and publish a draft release.
3. Publish the release is the final manual action. After publishing, a packit and PyPI releases are triggered automatically.

This is just an idea. Input is greatly appreciated.

[inknos]

adding a comment for reviewers and myself of the future
this is needed from Fedora side to pull tests and run gating in fedora PRs
https://src.fedoraproject.org/rpms/python-podman/pull-request/57#request_diff

[Honny1]

I have one nit. Otherwise, LGTM! We just need to test it and probably address any potential issues.

[Honny1]

Non-blocking: Should be solved as a follow-up pr.

This script updates 6 files, but pyproject.toml already has TODOs to enable dynamic versioning from podman/version.py:

# TODO: remove the line version = ... on podman-py > 5.4.0 releases
# dynamic = ["version"]
# version = {attr = "podman.version.__version__"}

And the Makefile could derive the version at build time instead of hardcoding it.

Resolving this tech debt first would reduce the script to only updating 3 files (podman/version.py, podman/tests/__init__.py, plans/main.fmf) and make the release automation simpler and less fragile.

[inknos]

@Honny1 addressed the debt in makefile too

[inknos]

/packit retest-failed

[inknos]

@Honny1 ptal

[Honny1]

LGTM. One small note: the PyPI release is triggered by pushing the tag, not by publishing the GitHub release. Is this good?

[inknos]

mmmh, maybe we could change the PyPI release to run on GH release. I think the one that's in the python guides uses the tag and I didn't change it

[Honny1]

LGTM