Fix StringRef build failure with newer libc++

[tsukinoko-kun]

Fixes #8306.

Summary

Building DXC with newer Apple toolchains fails in include/llvm/ADT/StringRef.h because libc++ now rejects user specializations of certain standard library traits. DXC currently specializes:

• std::is_nothrow_constructible<std::string, llvm::StringRef>
• std::is_nothrow_constructible<std::string, llvm::StringRef &>
• std::is_nothrow_constructible<std::string, const llvm::StringRef &>
  On Xcode 26.4 / Apple clang 21 / libc++, that now produces an error like:

is_nothrow_constructible cannot be specialized: Users are not allowed to specialize this standard library entity

What this changes

This patch keeps the existing HLSL workaround for non-libc++ standard libraries, but disables those std::is_nothrow_constructible specializations when building against libc++:

#if !defined(_LIBCPP_VERSION)
...
#endif

Why this fixes the issue
The failure is caused by the specializations themselves, not by any runtime behavior in StringRef.
For libc++:

• the specializations are now ill-formed and rejected at parse time
• libc++ already computes std::is_nothrow_constructible<std::string, llvm::StringRef> correctly without the workaround
  So the fix is to stop declaring the forbidden specialization on libc++, while preserving the existing behavior everywhere else.
  Why I chose this approach
  I looked at the HLSL-specific block in StringRef.h and tested the current Apple libc++ behavior directly. Without the manual specialization, libc++ still reports the relevant is_nothrow_constructible cases as false, which matches the intent of the original workaround.
  That made this the narrowest safe fix:
• it resolves the Xcode/libc++ build break in DirectXShaderCompiler vendored in SDL_shadercross fails to build with Xcode 26.4 / Apple clang 21 on macOS #8306
• it does not change runtime code generation or ABI
• it preserves the original workaround for non-libc++ environments where it may still be needed
  Validation
  I verified:
• the original header fails to compile with current Xcode/libc++
• after this change, the header compiles cleanly
• on libc++, the relevant std::is_nothrow_constructible instantiations still evaluate to false

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[pow2clk]

@damyannp I agree with the argument made in #8303 that the static asserts ensure that, on all currently supported compilers, the static asserts verify that this explicit manipulation isn't required anymore. I tested my own fix very similar to that approach on VS 2017 and others and found no issues. Maybe @tex3d remembers the history here.

That said, at this point, the compiler will not build on macos, so this or something similar really needs to go in. I have my own fix with a couple new mac compiler warnings fixed too here if you're interested pow2clk@ea596b1

[bogner]

Do we need to keep the workaround for non-libc++ standard libraries? The comments in #8303 strongly suggest we can just remove this completely.

[damyanp]

Do we need to keep the workaround for non-libc++ standard libraries? The comments in #8303 strongly suggest we can just remove this completely.

Maybe the test added in minchopaskal@9903286#diff-2f6bf948cfb0de9574a698d2a6fc79359d333c73fb62a9d357ace4bc2d86a4c3 would be enough to give us confidence?

[tsukinoko-kun]

I suggest fixing compiler errors first, then later removing workarounds. I don't care if you use my PR or any other fix.
It's a "make it work again ASAP" without breaking anything.

[tsukinoko-kun]

The required microsoft.DirectXShaderCompiler check seems to be stuck in ‘Expected — Waiting for status to be reported’. Could a maintainer please trigger/re-run the Azure pipeline?