Add infra for testing release build CI before a real release

[movermeyer]

What are you trying to accomplish?

Another step towards building #26.

We release so infrequently that there's almost always something that with our release workflow has broken due to "bit rot". This PR aims to add a mechanism for testing the release workflow before performing an actual release.

What approach did you choose and why?

Originally, I wanted this workflow test to occur with the creation of a Draft Release in the GitHub UI. Unfortunately, the release event is not fired for draft releases, so instead I had to use a manual workflow_dispatch event.

I've documented the new process for releasing backports.datetime_fromisoformat in docs/RELEASING.md. At a high level:

1. Update the version in pyproject.toml and add an entry to CHANGELOG
2. Manually trigger the publish workflow with the version in pyproject.toml
3. Verify that the sdist and wheels were built correctly, uploaded to https://test.pypi.org, and that they work when downloaded.
   • If something has broken, fix it and manually trigger the workflow again. It is designed to automatically increment the developmental release number used so Test PyPI doesn't complain about conflicts.
4. Create a GitHub release

I've added these steps into a new docs/RELEASING.md document.

What should reviewers focus on?

🤷‍♂️ Whatever you'd like.

The impact of these changes

Hopefully, we'll get to a point where we can run the workflow as many times as we want as tests, creating only "developmental releases" on PyPI, before we actually release to PyPI.