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.
SI-8023 Fix symbol-completion-order type var pattern bug

Removing the `isComplete` check altogether leads to cycles in,
for instatnce, F-bound type parameters:

    trait LSO[+A, +Repr <: LSO[A, Repr]] // error: illegal cyclic reference involving type Repr

But, I believe that we can (and must) eagerly initialize the type
parameter symbols if we are typechecking a pattern.

While this appeared to regress in 2.11.x, but the problem was in fact
dormant and was merely uncovered in the fix for SI-7756, 3df1d77fc.
Fixes SI-8014, regression in Vector ++ TraversableOnce.

Now uses the cached copy instead of the exhausted iterator.  Adds a JUnit
test for ++.
SI-8023 Address review comments around typedHigherKindedType

  - Make `WildCardType` kind polymorphic
  - Factory methods for expected kinds. They are still just
    `Type`-s, though.
  - Check if the type parameter is initialized, rather than
    its owner.
  - Take advantage of these to cleanup `typedAppliedTypeTree`

TODO: is this comment totally accurate? If so, should we
refactor `Kind.FromParams(tparams)` to `Kind.Arity(tparams.length)`?

     // @M: kind-arity checking is done here and in adapt,
     //     full kind-checking is in checkKindBounds (in Infer)
SI-7373 Make the constructor of Vector non-public

The danger of:

   new Vector(1, 2, 3).toString
   java.lang.NullPointerException

and the "should have been private all along" argument
call for a break in the source compatibility policy here.
better error messages for various macro definition errors
Merge pull request #3212 from retronym/ticket/8023

SI-8023 Fix symbol-completion-order bug of type var patterns
Merge pull request #3215 from retronym/ticket/7373

SI-7373 Make the constructor of Vector non-public
Merge pull request #3202 from retronym/topic/function1-tuplen

Diminished Tuple Confusion
Merge pull request #3213 from Ichoran/issue/8014

Fixes SI-8014, regression in Vector ++ TraversableOnce.
Merge pull request #3216 from xeno-by/topic/macro-error-messages

better error messages for various macro definition errors