Python 3.14 support (and related CI improvements)

[ulgens]

I was checking the repository to understand if I can run demos with the latest Python and I found out several points that I believe can be improved.

The general flow to add support for new Python versions is as follows:

1. Check trove classifiers to see if a list of supported version is declared.
2. Check if pyupgrade is running in CI, add it if not so.
3. Clean the repository using pyupgrade if needed.
4. Understand the test matrix, try to add the new version.
5. Continue with fixes if needed.

I applied the same flow to the repository, and I found a couple of points that I can help to improve, but I didn't want to create multiple PRs before discussing them first.

1. No issues with classifiers.
2. pyupgrade wasn't included in the lint config. Ruff runs in CI, I can enable the "UP" rules in ruff config, but it seems the repository doesn't have a ruff config. Alternatively, it can be enabled as a pre-commit hook. There are multiple ways that this can be handled, and I'd like to ask if there are any opinions on that matter.
3. While testing with pre-commit (as a pre-commit hook), I found a couple of other issues:
   • pre-commit hooks are not being checked in CI. ruff and mypy are called in separate steps, but not "pre-commit-hooks". Because of that missing check, running the hooks on the latest version creates a huge diff: Apply pre-commit hooks #236 Having this dissonance between the configuration and the CI creates an unnecessary barrier to potential contributors.
   • mypy and ruff invoke configs are duplicated. CI can call them using prek/pre-commit and use the same config everywhere. Also mentioned in CI improvements #197 (comment). Even better, the workflow doesn't need to know about hooks and can run everything by just calling prek/pre-commit run --all-files.
   • mypy has its own pre-commit hook: https://github.com/pre-commit/mirrors-mypy It can be used in hooks config instead of the current manual approach.
4. There wasn't a test matrix, I'm a bit surprised by this finding. Even though the package declares support for multiple Python versions, the tests run only against one specific version, and the others are not tested in CI.

I'm willing to contribute to these items, but because my previous PR got duplicated and then closed (#100). I wanted to check if you have any plans or ongoing work for these issues, and what your overall approach is to supporting different Python versions.