Adapt function arguments to n-ary prototype

[odersky]

If a function argument is a synthetic term of the form

x$1 => x$1 match case (a_1, ..., a_n) => e

and the expected type is an n-ary function type, rewrite the argument to

(a_1, ..., a_n) => e

Fixes #14626.

The example in #14626 now compiles without an implicit tupling conversion.
Such a conversion was inserted before in 2.13, 3.0 and 3.1.

[dwijnand]

Looks nice!

[griggt]

This is very appealing, however is the following change in semantics expected?

@main def Test =
  val xs = for {
    (a, b) <- List("a", "b", "c").lazyZip(List(1, 2, 3))
  } yield { println(s"computing $a + $b"); a + b }
  println("and the result is:")
  println(xs.toList)

$ scalac lazyzip.scala && scala Test
and the result is:
computing a + 1
computing b + 2
computing c + 3
List(a1, b2, c3)

$ scalac -source:future lazyzip.scala && scala Test
computing a + 1
computing b + 2
computing c + 3
and the result is:
List(a1, b2, c3)

I suppose this could be considered an implementation detail, and anyone unwittingly relying on the current behavior should have written

-  (a, b) <- List("a", "b", "c").lazyZip(List(1, 2, 3))
+  (a, b) <- List("a", "b", "c").lazyZip(List(1, 2, 3)).view

[odersky]

I think the expectation always was that the program is equivalent to

@main def Test =
  val xs = List("a", "b", "c").lazyZip(List(1, 2, 3)).map { (a, b) =>
    println(s"computing $a + $b"); a + b
  }
  println("and the result is:")
  println(xs.toList)

So the old behavior would count as a bug, IMO.