[clang] [HLSL] Don't invoke `dxv` from `clang-dxc` for text output (PR #135876)

[Martin Storsjö via cfe-commits]

mstorsjo wrote:

> These tests that run `env PATH="" %clang_dxc ...` are problematic for my setup for running tests on Windows.
> 
> In my builds, I'm building with a dynamically linked `libc++.dll` provided by my toolchain, which is available in `$PATH`, so the built `bin/clang.exe` requires finding this `libc++.dll` when executed. Normally this works fine, but when invoking tests that do `env PATH="" %clang ...` then `%clang` will run in an environment where it no longer finds its required `libc++.dll` in `$PATH`, and thus fails.
> 
> Previously, we've waived such issues by omitting that kind of tests on Windows (where setting `PATH` also affects where dependent libraries are found) by wrapping `%if !system-windows %{ ... %}` around those bits - see [f5a93c5](https://github.com/llvm/llvm-project/commit/f5a93c5f2a4d0916c975bbf028768d58a29b6b73).

Ping - any opinion on the above?

In theory, we'd have the same issue also for MSVC/clang-cl based builds with `/MD` (or `CMAKE_MSVC_RUNTIME_LIBRARY= MultiThreadedDLL`) - however there, the compiler support DLLs are found in systemwide default paths, so they're found even if running with a cleared `PATH` variable.

I've worked around this issue on my end for now by just manually copying in the host compiler DLL dependencies into the `bin` build directory before running tests. It works but it's not very pretty. (But if we deem this to be the way to go going forward, we should probably revert f5a93c5f2a4d0916c975bbf028768d58a29b6b73 as well.)

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