Deprecates Par*View and Gen*View

In 2.12, this gives us the option to move the code from
Gen*View down into *View. If we don't do something more
drastic with views, which inertia and history suggests
is a real possibility, we can at least shed a little of
the implementation.

These abstractions are *only* used to share implementation;
there is no `view` method available on, for instance, `GenSeq`
that lets one abstract over parallel/sequential collections
while spawning views.

  scala> (List(1): collection.GenSeq[Int]).view
  <console>:8: error: value view is not a member of scala.collection.GenSeq[Int]
                (List(1): collection.GenSeq[Int]).view
                                                  ^
Let's keep it that way.

I suspect that views over parallel collections exist not because
they were the most sought after feature, but rather because the
initial incarnatin of parallel collections used to live undernead
TraversableOnce, and hence were obligated to implement `def view`.

This change will give us deprecation warnings in the non deprecated
places that extend `Gen*View` (three, by my count) in the interim.
There are ways to avoid this, but they aren't particularly appealing.
Removes Gen*View and Par*View

 - code that used to be inherited in *View is now inlined
 - the `view` methods on `ParIteratoa` and `ParSeq` now
   convert to sequential collections, and are deprecated
   asking the user to do this explicitly in the future.

Should be largely source compatible with 2.10.x, on the assumption
that the removed classes, while being public, were internal
implementation details.

A few tests used now-removed classes to demonstrate compiler crashes.
I managed to confirm that after my decoupling, t4365 still exercises
the bug:

	% qbin/scalac test/files/pos/t4365/*.scala
	warning: there were 2 deprecation warning(s); re-run with -deprecation for details
	one warning found
	% scalac-hash 7b4e450 test/files/pos/t4365/*.scala
	warning: there were 2 deprecation warning(s); re-run with -deprecation for details
	one warning found
	% scalac-hash 7b4e450~1 test/files/pos/t4365/*.scala 2<&1 | grep -i wrong
	error: something is wrong: cannot make sense of type application
	something is wrong: cannot make sense of type application
	something is wrong: cannot make sense of type application

I didn't manage to do the same for specializes-sym-crash.scala,
and instead just made it compile.
Use -Dupdate.versions to update versions.properties
SI-8022 Backwards compatibility for Regex#unapplySeq

The change in ce1bbfe / SI-6406 introduced overloads of
`unapplySeq` with wider static and dynmaic result types
than the now-deprecated alternative that accepted `Any`.

This is subtly source incompatible and the change was noticed
in Specs2.

This commit uses `List` as the static and runtime type for
the new overloads.

For consistency, the same is done for the new method added
in SI-7737 / 93e9623.
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.
Merge pull request #3207 from retronym/ticket/8022

SI-8022 Backwards compatibility for Regex#unapplySeq
Merge pull request #3208 from dotta/si-7548-on-2.10

 askTypeAt returns the same type for full/ targeted typecheck (2.10.x)
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
SI-8013 Nowarn on macro str interpolation

When warning about stray "foo $bar" under `-Xlint`,
which may be missing an interpolator id, suppress
the warning if we're in the middle of a macro
expansion, since we have no useful heuristic to
apply to the expanded tree.

The test for whether the string is part of an
expanded tree is to check all open macros for
an expanded tree that contains the literal tree
under scrutiny. (This is deemed more paranoid
than looking for a macro application that is an
enclosing position.)
Merge pull request #3198 from adriaanm/update-versions

Use -Dupdate.versions to update versions.properties
SI-6913 Fixing semantics of Future fallbackTo to be according to docs

Origin: viktorklang@1bbe854