Revert "Inline _N case class product members under -Yscala2-stdlib"

[nicolasstucki]

These product members are only in the bytecode.

This reverts commit 8c58cbf.

[smarter]

Sorry, can you explain in more details why it's ok to leave these members?

[nicolasstucki]

These members should not be added at all. The inline version only removes them from the bytecode, but not from the pickles. I still need to find the correct solution to this issue. This PR only reverts the old, not quite right attempt to fix this.

I do not have a proper fix yet because this one is a bit more complicated than the others. Ideally we would just need to remove these members. But unfortunately, many other transformations depend on the existence of these members. One approach would be to patch all of the places where we use these member accessors and use the names of the fields directly. I need to see if this is viable. Otherwise, we could try to find another way, maybe remove them in the pickler.

[smarter]

But unfortunately, many other transformations depend on the existence of these members.

Does that happen in other transforms than pattern matching? The idea was that case classes wouldn't be handled specially for pattern matching in Scala 3 and instead rely on name-based pattern matching, but the logic for handling things by name still exists for Scala 2 case classes.

[nicolasstucki]

I just managed to make a proper fix for this in another branch. I will open another PR for that. I want to revert to this state as it uncovers a hole in TASTy MiMa that we should investigate.

It does not seem to affect pattern matching because all unapplys are adapted to return Options. They are handled as usual. We only need to patch desugaring and synthetic members.

[nicolasstucki]

Followed by #18117