[libcu++] Investigate MSVC issues with `__is_convertible` trait

One CI finding worth raising rather than quietly working around. The libcu++ nvcc MSVC builds fail on exactly one test out of 3771 — the new `meta.trans.other/common_reference.compile.pass.cpp` — at these two assertions, which I ported verbatim from libc++:

```cpp
static_assert(is_same_v, int>);
static_assert(is_same_v, int>);
```

I believe this is a pre-existing MSVC divergence that this PR merely exposes, rather than a regression from the sub-bullet 1 change: the expected result `int` is a prvalue, which can only come from bullet 6.3.3, and the new pointer-convertibility requirement can only make 6.3.1 *reject* more cases, i.e. push results toward 6.3.3 — it cannot turn a passing `int` into a failure. `common_reference.h` also carries an explicit `#if _CCCL_COMPILER(MSVC)` COND-RES workaround for DevCom-1627396, and the existing `concept.commonref` test only asserts the `common_reference_with` concept, never exact result types, so nothing exercised this before. I don't have MSVC available locally, so this is analysis rather than proof.

For now I've gated just those two assertions behind `#if !TEST_COMPILER(MSVC)` with a comment pointing at DevCom-1627396, keeping the coverage for every other compiler. Is that the call you'd prefer, or would you rather I drop them, or open a separate issue for the MSVC COND-RES divergence? Happy to go whichever way you think is right.

_Originally posted by @HenrikGharagyozyan in https://github.com/NVIDIA/cccl/issues/10582#issuecomment-5189642141_

Start with meta.trans.other/common_reference.compile.pass.cpp and the two MSVC-failing assertions, then read common_reference.h and its MSVC COND-RES workaround. Compare the nvcc MSVC behavior with the existing concept.commonref coverage and the DevCom-1627396 reference. Done means deciding whether to retain the compiler guard, remove the assertions, or track the divergence separately.

Written by the indexing model from the issue text.