Windows: OpenSSL installed DLL name differs from CPython, affecting extension modules

## The issue

On windows, there is a subtle difference between the installations of the python interpreter between what comes from `uv python install` and the distribution from `python.org`. The name of the OpenSSL DLL is different.

Python.org distribution:
`libssl-3.dll`
`libcrypto-3.dll`

uv python install:
`libcrypto-3-x64.dll`
`libssl-3-x64.dll`

## The cause of the issue

The `uv` [build script](https://github.com/astral-sh/python-build-standalone/blob/50e3f681bb441b78b07386ed1113f9c56716f433/cpython-windows/build.py#L668) seems to [configure](https://github.com/astral-sh/python-build-standalone/blob/50e3f681bb441b78b07386ed1113f9c56716f433/cpython-windows/build.py#L668) openSSL using the `configure|prefix` = `VC-WIN64A|64`

CPython does not document their configure/build scripts for OpenSSL. One of their maintainers updates [cpython-source-deps](https://github.com/python/cpython-source-deps/tree/bb01d0a37b909f6fe280b1c2015fa1f6005fb4e2) with thirdparty changes and uploads binary artifactos to [cpython-bin-deps](https://github.com/python/cpython-bin-deps/tree/openssl-bin-3.0.15), and then [copy from those binary deps](https://github.com/zware/cpython/blob/79d8063dfb0fd866d1ec21416cbec4dae839e65e/PCbuild/get_externals.bat) when packaging python. I looked on their issue tracker and forum and found some information ([1](https://bugs.python.org/issue34631), [2](https://bugs.python.org/issue46570), [3](https://github.com/python/cpython/issues/99079), [4](https://discuss.python.org/t/obsolete-pep-596-python-3-9-release-schedule-doubling-the-release-cadence/1828/7)) but no specific instructions. I am considering opening an issue on CPython to ask them to provide their build configurations for reproducibility.

## How are users affected?
If CPython distributes OpenSSL version 3.0.X using the dll name libssl-3.dll, and a CPython extension module links against OpenSSL version 3.0.Y using the dll name libssl-3-x64.dll, both Python and the extension module use the version of SSL that they were built against. When using `uv`, if version 3.0.X is distributed using libssl-3-x64.dll, then only one of these can be loaded into the process at a time, causing either the extension module or the python interpreter to fail depending on which DLL was loaded first. (For extension modules, Python's copy is loaded first, for embedding scenarios that use such an extension module, the extension module's version may be loaded first).

## Thoughts
This seems like a corner case not explicitly addressed by the maintainers of CPython, but according to Hyrum's law Python users could be affected. My opinion is that `uv` should match the behavior of CPython unless there is a specific reason not to (I didn't find anything in the uv history or source code indicating an intention to use a different DLL name than CPython). I also feel there should be clarification from the CPython developers on how they build binary dependencies like SSL and how extension modules ought to build against it.