This fixes building for x86_64-windows with no libc (for UEFI).
Otherwise, it would try to include a malloc header.

It makes sense to allow platform definitions to opt out of having libc
at all.  One use case would be targetting some obscure new Linux
target that doesn't have a libc implementation yet, and another is
UEFI, which is basically libc-less Windows.

Not having libc is not commonly specified in (GNU) triples (even
Linux's build system will just target either -gnu or -musl depending
on the platform), so instead, we use a separate attribute for it.

clangNoLibc always uses LLVM bintools, so it still has the useLLVM
semantics.

According to <https://gcc.gnu.org/legacy-ml/gcc-patches/2015-08/msg00836.html>,
all code is position-independent on Windows.  Some compilers
apparently warn for -fPIC on Windows, and clang errors:

> clang-15: error: unsupported option '-fPIC' for target 'x86_64-pc-windows-msvc'

I'm guessing the check was hostPlatform instead of targetPlatform by mistake.