Automate GitHub releases & PyPI package publication

[justinmayer]

This pull request adds a job to the existing GitHub Actions CI.yml workflow that uses AutoPub to automatically release and publish new packages to PyPI when a release file is merged or pushed into the main branch.

As part of this endeavor, I also took this opportunity to replace the twine upload step with PyPI's new Trusted Publisher system. In addition to the changes in this pull request, the only remaining step needed to utilize the Trusted Publisher system is for someone with more permissions than I currently have to do one of the following two things:

1. Send me an invitation to join the crispy-tailwind PyPI project with Owner role (my PyPI username is jmayer), after which I would be happy to set everything up.
2. Since @smithdc1 is currently the only person with access to the PyPI project, David can go to https://pypi.org/manage/project/crispy-tailwind/settings/publishing/, fill out the form with the values below, and submit the form.

Owner: django-crispy-forms
Repository name: crispy-tailwind
Workflow name: CI.yml
Environment name: (optional — can leave this field empty)

Rather than add PDM/Hatch as discussed in #149, I elected to defer that endeavor and instead retain Setuptools as the build back-end for now in an effort to keep the scope as narrow as possible.

Closes #149

[carltongibson]

This all looks very fancy. 😅

I'd lean to a release on tag kind of flow generally. Is it the case that every PR merged is release worthy? 🤔 (Maybe it is IDK 😜)

[justinmayer]

The idea is not that every single pull request merits a new release. Indeed, you probably don't want a new release to fix a typo in a code comment or to upgrade a linter dependency version. But thankfully that's not how this system is designed to work. 😊

The deployment machinery is only ever triggered when a RELEASE.md file lands in the main branch. That way:

1. If someone adds a release file when it isn't appropriate, maintainers can use the GitHub UI to remove the RELEASE.md file from a pull request if they feel a new release is not warranted. I do this occasionally, and it takes mere seconds.
2. If desired, maintainers can easily issue a release manually by pushing a RELEASE.md file directly to main, very similar to what you would expect from a release process based on Git tags.

I will add that I find this process to be much easier than messing with Git tags. You just choose major | minor | patch as the release type in the RELEASE.md file, and the version is automatically incremented accordingly, along with Git tagging, GitHub release creation, change-log updating, and of course package publication to PyPI.

Thanks to Florian, who made a number of improvements to the flow, you can see how this is handled in another Django-related project, Kagi.

[carltongibson]

Gotcha. That's kind of equivalent then. Sounds good. ("Very fancy" 😉)

[GitRon]

LGTM (except for the suggestion 🙃)! Thx for your effort!

[smithdc1]

David can go to ... fill out the form with the values below, and submit the form.

Done!

[justinmayer]

Thanks to Ronny and Carlton for reviewing, and thanks to David for the assistance with the PyPI configuration 💫