Drop in uv for pip (#10428)

It's a [drop-in
replacement](https://docs.astral.sh/uv/pip/compatibility/) that speeds
things up. I don't see any reason why not.

`--use-pep517` is [set by default](
https://docs.astral.sh/uv/pip/compatibility/#pep-517-build-isolation),
so we don't need it.

`--disable-pip-version-check` also does nothing on uv.

`uv` [uses
separate](https://docs.astral.sh/uv/pip/compatibility/#build-constraints)
`UV_BUILD_CONSTRAINT` and `UV_CONSTRAINT`. I just added it to both to do
the simplest thing here. We could split them.

We probably don't actually need to pipstrap pip anymore, I could take
that out.

What's happening with `parsedatetime` and `python-digitalocean` is that
they were always secretly wrong. Since `pip` compiles bytecode by
default, it was suppressing the errors. If you add the
`--compile-bytecode` flag to `uv`, it passes, but I don't think we
should do that. You can see the failure happen on main by passing
`--no-compile` to the pip args and running `certbot -r -e oldest`.

Now what I don't understand is that some places seem to say the `'\/'`
error from `parsedatetime` only started in python 3.12, whereas others
see it on earlier python. Perhaps pytest is vendorizing python or
something. Not too worried about that, needed to get updated anyway, and
it's an accurate oldest version based on our oldest OSes.
`python-digitalocean` is techincally newer than debian 11, but we've
made that decision before so it seems fine to me.

certbot/setup.py

@@ -33,7 +33,7 @@ install_requires = [
     'distro>=1.0.1',
     'importlib_metadata>=8.6.1; python_version < "3.10"',
     'josepy>=2.0.0',
-    'parsedatetime>=2.4',
+    'parsedatetime>=2.6',
     'pyrfc3339',
     # This dependency needs to be added using environment markers to avoid its
     # installation on Linux.