[clang] [clang] Support --sysroot= for ${arch}-windows-msvc targets (PR #96417)

[via cfe-commits]

trcrsired wrote:

> I don't recall it coming up here (although it did in #161400), but case sensitivity isn't all or nothing. https://github.com/llvm/llvm-project/blob/main/llvm/cmake/platforms/WinMsvc.cmake automatically sets up a case-insensitive VFS overlay just for the Windows SDK, for example.
> 
> I share your pain around the MSVC layout putting C and C++ headers into the same directory. In a past life I was using libc++ for Windows, and separating the MSVC C and C++ headers out (so libc++ could fit in) was annoying. I'm curious how Chrome deals with this, since IIRC they use libc++ on Windows.
> 
> From a cross-compiling perspective, I share @rnk's opinion that a Unix-like layout for a `--sysroot` option is a reasonable choice. Idk how reliable it is to shoehorn the MSVC and WinSDK headers into that shape (i.e. if there's any potential for fatal incompatibilities in the future), but I imagine it's kept working across the two years this PR has been open, which is promising.
> 
> In general I think making cross-compilation more accessible and having familiar options for it is a good thing. Zig's cross-compilation is extremely popular because of how seamless it is, for example. (FWIW, when I was working on this I found WinMsvc.cmake to work pretty easily apart from the C++ headers bit, but if you want to use libc++ then the C++ header bit is pretty important, unless I'm misremembering how things work.)

We can have another pr to deal with case sensitivity. not in this one. I guess case sensitivity is a llvm wide change, much bigger than this, since you would have to deal with lld(or linker won't be able to find libs such as Msvcrt.lib) and probably others. Also it should not be a default toggle for any platforms since case insensitivity does break things and did create security vulnerabilities in the past.

Let's first get this done since it will try to find both POSIX and /winsysroot and i really see no reason to object rather than some philosophical issues which should not be an issue to begin with given the fact we already have both clang-cl as a seperate frontend to emulate msvc behavior. clang/clang++ are gnu style behaviors to begin with.

https://github.com/llvm/llvm-project/pull/96417