SI-8574 Copy @SerialVersionUID, etc, to specialized subclasses

The test case demonstrates that this is important for serialization
and for strictfp. (Although the latter is still pretty broken,
see SI-7954.)

Now that the synthetic subclass of `Tuple2[Int, Int]` also has the
`@deprecatedInheritance` annotation, I had to change the spot that
issues this warning to be silent after the typer phase. Otherwise,
we get two warnings in `run/t3888.scala`. This also remedies double
warnings that were incurred in `neg/t6162-inheritance`.
Merge pull request #3738 from retronym/ticket/8574

SI-8574 Copy @SerialVersionUID, etc, to specialized subclasses
SI-8597 Improved pattern unchecked warnings

`matchesPattern` has a long and winding history. I believe that
two factors have contributed to the difficulty in getting it
right:

  - it has been used for two similar but subtly different purposes:
    checking the if the pattern type matches the scrutinee type,
    and vice versa.
  - we haven't had a way to identify pattern type variables (which
    includes wildcards) from other abstract types, due to the
    imprecise way they are encoded by `typedBind`.

This commit splits this into two methods, and updates callers
to use the pertinent alternative.

In `pattp patternTypeMatchesPt pt`, we still existentially abstract
over the arguments to the scrutinee type. If we didn't do this,
we would reject this match:

   def foo[T](as: Seq[T]) = as match {
      case _: List[Int] =>
   }

But, in `pt ptMatchesPatternType pattpt`, we now take a different
approach: we detect pattern type variables in `pattpt` and replace
them with wildcards.

Let's look at an example. In the reported bug:

    def nowarn[T] = (null: Any) match { case _: Some[T] => }

We used to determine that if the first case matched, the scrutinee
type would be `Some[Any]` (`Some` is covariant). If this statically
matches `Some[T]` in a pattern context, we don't need to issue an
unchecked warning. But, our blanket use of `existentialAbstraction`
loosened the pattern type to `Some[Any]`, and the scrutinee type
was deemed compatible.

Simply removing the use of `existentialAbstraction` in the newly
isolated `ptMatchesPatternType` is not correct, though. We still
need to ensure that this a scrutinee type of `Tuple3[Any, Any, Any]`
matches a pattern type of `Tuple3[_, a, Int]`.

I have introduced a new symbol test to (try to) identify pattern
type variables introduced by `typedBind`, and replaced these
by a wildcard type.
Introduce scaffolding for -Xsource:2.12

Any changes to implicit search or type inference that we want to
ship in the 2.11.x series should be guarded by this flag. This is
philosophically equivalent to `-Xfuture`, and indeed we should
try to merge these flags.

Such changes can only be added to 2.11.x if we can reason that they
will interop with separately compiled code that doesn't use
the flag. An example of a change that would not qualify: fixes that
modify the erased signatures (e.g. AsSeenFrom or ErasureMap); caller
and callee must agree on these matters.
SI-8597 Predicate change in inferTypedPattern on -Xsource:2.12

I haven't found a test that breaks with the change in place, but
lets play it safe and leave the old behaviour in place for 2.11.x.
SI-8597 A test variation to with nested matches

The pattern type of the inner case can't, syntactically, refer to the
pattern type variable of the enclosing case.