gh-159008: Delay load user32.dll in libcrypto on Windows - #159009

_hashlib and _ssl link libcrypto-3.dll. Its import table names three user32.dll functions:

• GetProcessWindowStation and GetUserObjectInformationW, used by OPENSSL_isservice();
• MessageBoxW, used by OPENSSL_showfatal().

Both are only reached from OPENSSL_die(), i.e. when OpenSSL aborts on an internal error. The
import is still resolved at load time, so import hashlib (and hmac, secrets, ssl,
asyncio, urllib.request, http.client ...) maps user32.dll, gdi32.dll, gdi32full.dll,
win32u.dll and imm32.dll into the process. A plain python.exe does not load any of them.
Since gh-155435, _ctypes no longer does either.

This links libcrypto with /DELAYLOAD:user32.dll. The three functions are then bound on first
call, on the abort path. The change is one line in PCbuild/openssl.vcxproj, so it takes effect
the next time the OpenSSL binaries in cpython-bin-deps are built with prepare_ssl.bat.

• LDFLAGS replaces the VC targets' default /nologo /debug, which is unchanged from 3.0 to 3.5.
• LDLIBS=delayimp.lib adds the delay-load helper; Configure still links the target's own
  ex_libs (ws2_32, gdi32, advapi32, crypt32, user32).
• libssl gets the same flag but imports nothing from user32. It links with LNK4199, a
  "/DELAYLOAD:user32.dll ignored" warning, and no other change.

Built with this branch's openssl.vcxproj: OpenSSL 3.5.9, x64, Release; msbuild PCbuild\openssl.vcxproj as prepare_ssl.bat runs it, once without and once with the change.

• dumpbin /dependents: USER32.dll moves to the delay-load table, and nothing else changes.
• The result goes into a 3.15.0rc3 embeddable distribution, which uses OpenSSL 3.5.9:
  • import hashlib loads no user32/GDI DLL;
  • test_hashlib test_hmac test_ssl test_httplib test_urllib2_localnet test_asyncio.test_ssl test_asyncio.test_sslproto pass: 679 tests, 44 skipped.
• OPENSSL_isservice() (exported), called from a small console program, still works: user32 is
  absent before the call and loaded by it, and the result (0) is the same as with the stock DLL.

Timing (one machine, i9-14900K, Windows 11; three copies of 3.15.0rc3 embeddable that differ
only in libcrypto/libssl; 20 interleaved passes, fresh process each; medians, paired
bootstrap 95% CIs):

On a 3.14.4 PGO build with OpenSSL 3.0.19, the same change measured −2.05 ms [−2.16, −1.95] for import _hashlib.

• Issue: Windows: import hashlib loads user32.dll and the GDI DLLs through libcrypto; delay-load user32 #159008