Handles Nothing when synthesizing CanEqual

[deniszo]

fixes #13739
fixes #13512

[SethTisue]

@dwijnand this might interest you — I saw you piped up at e.g. #12419 (comment)

[SethTisue]

on #13512, @jcracknell wrote:

With this addition it appears you can remove the supplementary CanEqual.canEqual{Seq,Option} previously added to address matching Nil/None in the above-mentioned commits.

not sure if this still applies? I can't look into it right this second, but I guess we should check on it before we merge this

[jcracknell]

This introduces a "fix" for #13512 which effectively introduces CanEqual[Any, Nothing] (and vice versa), and I just want to make sure that it was determined that this is the desired behavior.

As best I can tell it should be perfectly safe, as the given only applies in the case where one of the arguments is known to be Nothing, and there is no way to evaluate such a comparison in any case. The discussion in #12419 expressed some trepidation, although that occurred at the intersection of several issues that had not quite been teased apart.

Edit - for further clarity:

• Synthetic CanEqual for primitives does not handle Nothing as a subtype #13739 is about the fact that the synthetic CanEqual[Int, Int] supplied by the compiler does not behave as though it is contravariant, specifically in the case of Nothing.
• Equatability of Nothing with types which are otherwise unequatable #13512 is a design question wrt whether or not CanEqual[Any, Nothing] should be supplied by default.

As noted by @SethTisue elsewhere, the test case for the former that I had overlooked and is missing from this PR is summon[CanEqual[1, Int]], however that appears to work already:

https://scastie.scala-lang.org/BISPPkkYSaS8qstpCNbFOg

My biggest concern with the PR is that the implementation still never actually checks for a subtype relationship between the two types - only with java.lang.Number. While this appears to cover all the cases I can think of at the moment, I suspect a more principled approach might involve boxing both sides, checking for a relationship, and then checking if both derive from java.lang.Number as a fallback.

[smarter]

LGTM, strictEquality is sort of experimental (I think it should be under scala.language.experimental really) so I have no qualm merging this :).