mcpplibs:tinyhttps does not build for Windows under openkal: winsock2.h is not in the closure #435

mcpplibs:tinyhttps 0.3.0 fails to compile for any Windows target in an openkal graph: its socket
backend includes the Windows SDK's winsock2, which openkal does not supply.

mcpplibs-x-tinyhttps/0.3.0/tinyhttps-0.3.0/src/socket.cppm:4:10:
fatal error: 'winsock2.h' file not found

Reproduced on both paths CI takes: a native build on windows-2022, and a cross-build from Linux to
x86_64-windows-gnu. The Linux target builds fine and the library works well there.

Why it is absent rather than merely unfound. openkal-windows ships no headers at all --
neither does openkal-macos -- and every C header in the graph comes from openkal-musl. openkal's
shape is a POSIX C environment on every platform, with sockets available through its own API
(openkal.net in the consuming project, kal_* underneath). winsock2 is the host Windows SDK, so
a package that includes it directly is outside the closure on this target.

Worth noting because it hides on a developer machine: a Linux host that happens to have mingw
installed does have a winsock2.h, so the cross-build gets further there and then fails
differently -- on my machine it failed inside compat:zlib with musl/mingw header conflicts
instead. Whether the build fails, and how, depends on what is installed on the machine. I filed
that half as mcpp-community/mcpp#662, since the C compile is given --target and no
-nostdinc/--sysroot, letting clang's own sysroot search find the host's mingw.

What would fix it, in the order I would try them:

1. A socket backend over openkal's own socket API for openkal targets, so the library is
   platform-independent in the way the rest of the graph is.
2. Or declare the package unsupported on openkal Windows targets, so resolution fails with a clear
   reason instead of a missing header three minutes in.

Found while replacing a packaging tool's Python (urllib.request) with tinyhttps so the project
would stop needing an interpreter to download its payload inputs. The API fits well --
download_to_file with progress and redirects is exactly the shape needed; it is only the Windows
target that cannot build.