feat: replace setuptools with uv

[claui]

This PR replaces setuptools with uv to streamline dependency management.
This also allows for environment-specific requirements, which Aider needs for several use cases.

See #3469 (comment) for background and rationale.

@paul-gauthier Let me know what you think of this approach.

---

To do

• First draft
• Test the development workflow on Linux
• Test the development workflow on Mac
• Test the development workflow on Windows
• To confirm that this PR actually brings value, temporarily add a complex platform-dependent requirement, e.g. the NumPy/torch/x86/Mac problem from Bump NumPy to v2.0.2 for Python 3.13 compatibility #3444
• Check whether the wheels it produces actually work
• Make a test deployment (e.g. to TestPyPI or a local index) and check whether that works
• Check for regressions in the seamless-install feature (while temporarily using the test index instead of PyPI)

[claui]

For the record, I also attempted the same thing with Poetry as suggested in #3469 (comment) but ultimately abandoned Poetry in favor of uv for several reasons:

1. uv is already being used for bootstrapping the installer, which means there isn’t yet another tool to install, and project contributors may already be familiar with uv;

2. uv has gained a lot of traction and momentum, to the point that even the most notorious critics of project management tools are now endorsing it;

3. while I got Poetry mostly working, I couldn’t get the dynamic versioning part up and running (i.e., like setuptools-scm), and third-party replacements kept erroring out on me; on the other hand, the uv ecosystem has uv-dynamic-versioning, which when used in combination with uv and hatchling as a build backend, would Just Work.

[claui]

@paul-gauthier What do you think of this approach?

[counterposition]

One of the biggest benefits of uv is that you don't have to think about virtual environments at all, since uv manages it automatically. uv venv is largely intended for legacy workflows. There is no need to scaffold, activate, or deactivate virtual environments anymore.

I suggest avoiding the uv venv and uv pip commands for this reason.

[ei-grad]

Honestly, this looks so much cleaner than current setup...

[ei-grad]

Shouldn’t this decision be left to each developer’s local environment? Supporting multiple Python versions is inconvenient when one is hard-coded in the Git repository.

[claui]

For a package that wants to support multiple Pythons, pinning the oldest supported Python helps enforce the greatest common divisor in terms of language and API level. It’s just a guardrail for the developer so they can’t inadvertently use newer language features, which would break the library for users with older Pythons.

It also makes sure that every developer gets the same linting and typechecking findings.

With that being said, the file is only a hint for tools at venv creation time. If a developer absolutely must override this (even though I think this is a bad idea), they’re free to ignore this file and just create a custom venv with a Python version of their choosing.

[ei-grad]

Yes, indeed. I assumed this file would take precedence and didn’t realize it can be overridden by the UV_PYTHON environment variable or the --python flag. It might be worth noting this in CONTRIBUTING.md.