Update comments on TASTy MiMa filters

[nicolasstucki]

[skip ci]

[nicolasstucki]

@sjrd I don't remember what you said about

// Problem: ???
ProblemMatcher.make(ProblemKind.MissingTermMember, "scala.Predef.nn"), // The member scala.Predef.nn with signature (1,java.lang.Object):java.lang.Object does not have a correspondant in current version
ProblemMatcher.make(ProblemKind.MissingTermMember, "scala.Predef.ne"), // The member scala.Predef.ne with signature (java.lang.Object,java.lang.Object):scala.Boolean does not have a correspondant in current version
ProblemMatcher.make(ProblemKind.MissingTermMember, "scala.Predef.eq"), // The member scala.Predef.eq with signature (java.lang.Object,java.lang.Object):scala.Boolean does not have a correspondant in current version

[sjrd]

nn, eq and ne are weird. Also other methods patched onto Predef from stdLibPatches.

When tasty-query reads Predef from a Scala 2 pickle, it artificially adds those methods. This imitates somewhat what dotc does, except that dotc generically copies from stdLibPatches whereas tasty-query hard-codes the patches.

When reading from TASTy, however, the code paths are different and tasty-query does not apply the patches.

So if the TASTy stdlib does not include those methods directly in the TASTy of Predef, TASTy-MiMa will complain.

Whether this should be fixed in tasty-query or in the TASTy of Predef is unclear. Ideally Since we want to eventually use the TASTy stdlib to enhance other parts of the library, it would be good to also do it directly for Predef.

[nicolasstucki]

Whether this should be fixed in tasty-query or in the TASTy of Predef is unclear. Ideally Since we want to eventually use the TASTy stdlib to enhance other parts of the library, it would be good to also do it directly for Predef.

Following up in #19231. This adds the first step towards defining everything directly on Predef.