Consider extending Clang-CUDA support/testing

Related to #2075. Possibly related to #1598, if Clang-CUDA requires a recent NVIDIA CUDA Toolkit to be installed.

Test coverage

Currently, we have no test coverage for Clang-CUDA. If this scenario is important to some users (as it appears to be) and is likely to be damaged as we modify preprocessor logic for Clang and CUDA separately, we should have test coverage to prevent major/obvious regressions.

__CUDACC__ preprocessor logic

Also, if this is important, we should audit the codebase for places where we're testing __CUDACC__ but Clang-CUDA could handle the normal codepath instead of needing the workaround codepath. (I suspect that Clang-CUDA can handle the normal codepath when "front-end stuff" is involved, but that we need the workaround codepath when "codegen intrinsic stuff" is involved.)

Current examples:

Already patched

• https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/yvals_core.h#L428-L432
  Already patched by @CaseyCarter in #2208! 🎉 (This is a good example of "front-end stuff".)
• https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/yvals_core.h#L586-L592
  This is what #2075 is patching.

No action necessary

• https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/cmath#L15-L16
  Codegen intrinsics, excludes both Clang and CUDA, no action necessary.
• https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/limits#L19-L21 https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/limits#L1054-L1056 https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/limits#L1157-L1159
  These are all codegen intrinsics.
• https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/type_traits#L636-L639 https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/type_traits#L661-L664
  This front-end __is_assignable_no_precondition_check makes MSVC behave like Clang, thus I believe there's no need to investigate making Clang-CUDA take this path.
• https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/yvals_core.h#L438-L441
  This is for MSVC-specific type trait optimizations. No reason to make Clang-CUDA use this.
• https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/yvals_core.h#L556-L563
  We already test for Clang before CUDA here, no action necessary. (Ditto for the restore macro below.)

Possible enhancements

• https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/functional#L858-L859
  Front-end SFINAE, I suspect that Clang-CUDA doesn't need this workaround. (Also applies to #2124.)
• https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/xutility#L36-L40 https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/xutility#L66-L73
  Clang-CUDA might be capable of using __builtin_bit_cast.
• https://github.com/microsoft/STL/blob/303df3dae6f5ed9fe4f1c35257f663af8355584a/stl/inc/yvals_core.h#L450-L451
  Front-end stuff: Clang-CUDA likely supports "conditional explicit" in all Standard modes, so making it use the modern path would be good (as we already do for vanilla Clang).

Start by reviewing the Clang-CUDA-related CUDACC checks in stl/inc/functional, stl/inc/xutility, and stl/inc/yvals_core.h, along with the examples in stl/inc/cmath, stl/inc/limits, and stl/inc/type_traits. Determine which paths need Clang-CUDA coverage and which can use normal Clang handling. Done means relevant tests exist and the audit's necessary preprocessor changes are covered against regressions.