[clang] Fix assertion failure during conversion function overload resolution. (PR #98671)

[Richard Smith via cfe-commits]

zygoloid wrote:

Hmm. See https://lists.isocpp.org/core/2024/06/15952.php -- I think we should never be comparing constraints between functions whose signatures aren't otherwise the same, and in particular we should never compare the constraints of a conversion function template against the constraints of a conversion function.

Conversion functions do add another wrinkle here, because we can find them in different scopes too. For example:

```c++
template<typename T> concept C = true;
template<typename T> concept D = C<T> && true;

template<typename T>
struct A {
  operator T() requires C<T>;
};

template<typename U>
struct B {
  operator U() requires D<U>;
};

struct X : A<int>, B<int> {};

int n = X();
auto p = &X::operator int;
```

It doesn't make sense to compare the constraints of the conversion functions of the two templates here, because `T` simply has nothing to do with `U`. (Today, Clang and MSVC report ambiguity for both `n` and `p`; GCC and EDG accept `n` but reject `p`.)

That said... an example like the following sidesteps all these issues and still crashes clang, so I think the above comments are somewhat orthogonal to this patch (except that I think we should have something like this as a test case instead of the current test case):

```c++
template<typename T> concept C = true;
template<typename T> concept D = C<T> && true;

struct X {
  template<C T> operator T();
  template<D T> operator T();
};

auto p = &X::operator int;
```

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