SI-8597 Improved pattern unchecked warnings

The spec says that `case _: List[Int]` should be always issue
an unchecked warning:

> Types which are not of one of the forms described above are
> also accepted as type patterns. However, such type patterns
> will be translated to their erasure (§3.7). The Scala compiler
> will issue an “unchecked” warning for these patterns to flag
> the possible loss of type-safety.

But the implementation goes a little further to omit warnings
based on the static type of the scrutinee. As a trivial example:

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

need not issue this warning.

These discriminating unchecked warnings are domain of
`CheckabilityChecker`. It was written in terms of
`X matchesPattern P`, where `X` is the scrutinee type and `P`
is the pattern type.

`matchesPattern` internally approximates erased type tests
by existentially abstracting over abstract types in the pattern
type. `X <:< existentialAbstraction(P.typeArgs, P)`. (Arrays are
special cased).

However, this answers the wrong question when it comes to
unchecked warnings.

Let's deconstruct 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.

I believe this tells us that we shouldn't be using `matchesPattern`
for unchecked warnings.

I've added a new method, `scrutConformsToPatternType` which replaces
pattern type variables by wildcards, but leaves other abstract
types intact in the pattern type.

I have introduced a new symbol test to (try to) identify pattern
type variables introduced by `typedBind`. Its not pretty, and it
might be cleaner to reserve a new flag for these.

I've also included a test variation exercising with nested matches.
The pattern type of the inner case can't, syntactically, refer to the
pattern type variable of the enclosing case. If it could, we would
have to be more selective in our wildcarding in `ptMatchesPatternType`
by restricting ourselves to type variables associated with the closest
enclosing `CaseDef`.

As some further validation of the correctness of this patch,
four stray warnings have been teased out of
neg/unchecked-abstract.scala