CI: advance the Python version support window

[jayaddison]

• Confirm locally that the testsuite passes (except for two expected failures) using version 3.13 of Python.
• Confirm that main GitHub Actions continuous integration test workflow passes using the same.
• Update other GitHub Actions workflows to use py3.13
• Update package metadata and internal references to indicate support for py3.13
• Add a changelog entry

Contributor checklist

• Included tests for the changes.
• A change note is created in changelog.d/ (see changelog.d/README.md for instructions) or the PR text says "no changelog needed".

Maintainer checklist

• If no changelog is needed, apply the skip-changelog label.
• Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

Resolves #2138.

[jayaddison]

My availability to respond to review feedback and/or support this changeset next week will be limited; please keep that in mind if considering potential merge/release inclusion.

[webknjaz]

This mustn't be in a section with random unimportant changes. There's a removal and addition of support. There's respective sections for both.

Although, I don't think we're in rush to drop 3.8 right away. Is it causing problems?

[jayaddison]

Ok; would it be preferable to isolate this into two changesets, one to add Python3.13 as a feature change note, and then potentially a Python3.8 deprecation?

I'm not aware of any problems due to Python3.8 here, nope - my main motivation was to maintain a similar level of CI resource usage/cost, despite exercising an extra Python version.

In fact: I also note that I omitted to update the requires-python directive in the pyproject.toml here; so in fact this changeset does not entirely remove Py3.8 support, as it stands.

[sirosen]

I would treat two PRs as preferable, yes.

Adding and removing versions touches different metadata, e.g., Requires-Python when the lower bound moves.

Upon reflection, I don't think we're ready to drop 3.8 quite yet. This is open to debate, but I'd like to do one more bugfix release before removing a version (even an EOL one; lots of orgs move versions slowly).

Once we don't support 3.8, a series of small cleanups come into play, e.g., the black and pyupgrade version numbers. I think I prefer to do those separately from the version bump as well, which I would confine to package metadata and CI configuration.