Improve productivty when user-defined `==` overloads aren't selected due to nilability

[bradcray]

[split off from https://github.com//issues/28269#issuecomment-3717092534]

I recently ran into an issue in which I thought I'd defined an == operator for my class:

operator ==(x: C, y: C) {
  writeln("In my == operator");
  return x.x == y.x;
}

only to have it not be selected because the arguments being compared with == were nilable and my overload only handled non-nilable versions. This caused some confusion for me because the == still resolved to the compiler-generated version, so didn't cause resolution errors, but also didn't call into the routine I'd been (incorrectly) anticipating that it would.

Here, I'm proposing we do something to improve user productivity in this case, which could be:

• warning when a compiler-generated routine is selected over a user-written routine whose only difference is in terms of nilability
• having the presence of any == overload on classes squash the compiler-generated overloads (and similarly for other routines that the compiler generates
• having the compiler-generated == operator that handles nilability be implemented in terms of a user-defined non-nilable case like the above
• something else

Basically, this felt like a silent failure that was hard to debug (in my case compounded by the fact that the == itself was being called from another compiler-generated ==) and it felt like we could be doing more to help such users.