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.