Fix right associativity of extension methods

[nicolasstucki]

This patch removes the special treatment of extension methods while desugaring. Instead of swapping the arguments of the extension method at definition site, we let the usual desugaring take care of it.

extension (xs: List[Int]) def -:(x: Int) = xs.remove(x)

1 -: List(2, 3) // desugars into List(2, 3).-:(1)
1 :: List(2, 3) // desugars into List(2, 3).::(1)

This implies that the following makes sense now:

List(2, 3).-:(1) // equivalent to the one bellow
-:(List(2, 3))(1)

Note that the parameters are passed in order as in the signature, as they should. This used to break intuition in the previous implementation.

Futhermore, this fixes parameter scoping and dependencies, as it trivially respects the original signature. An example of this is in the following code example, where T is bounded by tuple.type, which would have been out of scope in the previous implementation due to the swapping of parameters.

extension (tuple: Tuple)
  def *:[T >: tuple.type <: Tuple, H](x: H): H *: T = ...

The downside is that this is a breaking change as we change the semantics of the extension method definitions. We need to find a way to migrate from one to the other without breaking code. One option might be to have a different syntax for the new semantics, and deprecate the old one. One possibility would be to use infix def extensions to mark to mark these methods.

One issue encountered in the library is with the IArray.{++:, +:} operations. Luckily, it seems that by rewriting them into the new semantics we get a binary and TASTy compatible signature.

Fixes #19197
Needs SIP

[dwijnand]

I think the previous behaviour is a bug, so it's a behaviour fixing change.

But also:

extension (xs: List[Int]) def -:(x: Int) = xs.remove(x)

1 -: List(2, 3) // desugars into List(2, 3).-:(1)
1 :: List(2, 3) // desugars into List(2, 3).::(1)

Could you make sure it desugars properly to:

        val x$1: Int = 1
        List(2, 3).-:(x$1)

like we do for infix class methods, as I think changing the order of evaluation of the left and right-hand side would also be a bug. I.e. some test where you use side-effects to assert the execution order.

[nicolasstucki]

       val x$1: Int = f
      List(2, 3).-:(x$1)

This is already the current desugaring when the argument is knownt to be pure. I used a simpler example to only have to show how the method is called.