[v2] Port Python 3.13 support to v2 branch

[jamesls]

This cherry-picks 0334e63 from #2137 and resolves the necessary conflicts to get it to build successfully.

I'm not sure how we want to handle changelog entries for 2.0 changes so I've not added a jmeslog entry for this. Couple of thoughts though:

• Don't think jmeslog supports versions other than X.Y.Z, and you'd have to have some specification on the tag after the patch version should be (e.g. pep440), not sure if it's worth adding python-specific pre-release logic to jmeslog itself.
• I suspect we may have larger upgrade steps as large pieces get rewritten or redesigned. We may be better off with a more general v2 upgrade guide.

Given the potentially large number of changes, it might be better to just rely on the PR tags/titles to collect all v2 changes together. Not sure how often we're going to be cutting pre-releases of v2 so I'm deferring that until later.

cc @jonathan343

[jonathan343]

Why are we deleting this file? This is used by uv to automatically install the specified version of python and create a related virtual environment:

The .python-version file can be used to create a default Python version request. uv searches for a .python-version file in the working directory and each of its parents.

Source: https://docs.astral.sh/uv/concepts/python-versions/#python-version-files

Alternatively, because chalice devs may often need to have multiple versions of Python installed, we can use the .python-versions file with the following contents:

3.13
3.12

By default uv python install will verify that a managed Python version is installed or install the latest version. If a .python-version file is present, uv will install the Python version listed in the file. A project that requires multiple Python versions may define a .python-versions file. If present, uv will install all of the Python versions listed in the file.

Source: https://docs.astral.sh/uv/concepts/python-versions/#installing-a-python-version

[nateprewitt]

.python-version is largely intended for use in an application rather than a library. It helps ensure reproducible builds when testing and deploying. Adding it to a library is a little odd because you don't know the intent of the user. uv falls back to the users global .python-version if one isn't defined in the project which we generally shouldn't be overriding without good reason.

I'm not sure adding a bunch of versions here actually provides benefit to typical end user.

[jonathan343]

Got it. I'm mainly worried about someone who may have an unsupported version configured as their default. For example, if I'm using 3.11 and only 3.12+ is supported. I just learned that uv will throw the following warning:

$ uv venv -p 3.11
Using CPython 3.11.11
warning: The requested interpreter resolved to Python 3.11.11, which is incompatible with the project's Python requirement: `>=3.12`
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate

This makes me less worried since it makes the user aware they're using an unsupported version when they create the virtual environment.

[nateprewitt]

Yep, python_requires is the intended method for libraries to dictate supported versions. pip/uv should take care of the rest.