Better error messages for common Function/Tuple mistakes

Firstly, for `((a, b) => c): (Tuple2[A, B] => C)`, we currently
just offer "missing parameter type." Is something of a rite of
passage to know that you need `{ case (...)}`

This commit stops short DWIM, but does offer a diagnostic to guide
the user towards the supported way of destructuring a `Tuple` in
the sole argument of a `Function1`.

Secondly, another (less common?) way one might try to write a function
to destructure a single tuple argument is:

    (((a, b)) => c)

The parser now matches offers a specific error message for this, and
points out the alternatives.

In both cases, we avoid offering syntactically invalid alternatives,
by detecting names that aren't valid as variable-patterns, and
falling back to generic "paramN" in the error message.

A handly utility function to sequence a list of options is liberated
from the pattern matcher for broader use.

1 files changed, 8 insertions, 0 deletions

diff --git a/test/files/neg/missing-param-type-tuple.scala b/test/files/neg/missing-param-type-tuple.scala
new file mode 100644
index 0000000000..72c0c82034
--- /dev/null
+++ b/test/files/neg/missing-param-type-tuple.scala
@@ -0,0 +1,8 @@
+class C {
+
+  val x: ((Int, Int)) => Int = (a, b) => 0
+
+  val y: ((Int, Int, Int)) => Int = (a, b, !!) => 0
+
+  val z: ((Int, Int, Int)) => Int = (a, NotAVariablePatternName, c) => 0
+}