SI-8475 Fix off by one in GroupedIterator when Streaming

This also affected sliding and grouped since they defer to GroupedIterator
SI-8617 Avoid rangepos crash for OptManifest materializer

The tree to create a `NoManifest` was unpositioned.
Merge pull request #3790 from retronym/ticket/8617

SI-8617 Avoid rangepos crash for OptManifest materializer
Eliminate some N^2 performance in type checking

Where N is the number of members of the enclosing package.

Double definition errors for top level classes/objects are issued
elsewhere, as demonstrated by the enclosed test. So we can
omit the call to `checkNoDoubleDefs` in this content.

We can't omit the call to `addSynthetics` for package
class owners (case- and value-class synthetic companions
are added here), but we can make the process cheaper by
moving the expensive-but-usually-true call to `shouldAdd`.

Here's an example of the improvement.

    % rm -rf /tmp/pkg; (for i in {1..50}; do for j in {1..100}; do echo "package pkg { class A_${i}_${j}___(val a: Int, val b: Int) }"; done; done) > sandbox/A1.scala && time scalac-hash v2.11.0 -Ybackend:GenASM -J-Xmx1G -J-XX:MaxPermSize=400M -d /tmp sandbox/A1.scala;

    real    0m49.762s
    user    1m12.376s
    sys 0m2.371s

    % rm -rf /tmp/pkg; (for i in {1..50}; do for j in {1..100}; do echo "package pkg { class A_${i}_${j}___(val a: Int, val b: Int) }"; done; done) > sandbox/A1.scala && time qbin/scalac -Ybackend:GenASM -J-Xmx1G -J-XX:MaxPermSize=400M -d /tmp sandbox/A1.scala;

    real    0m35.662s
    user    0m58.275s
    sys 0m2.355s

We've still got another source of pathological performance in
creating nested scopes that I'll fix in the next commit.
Optimize nested scope creation

We can copy the hash table from the parent scope, rather
than constructing it from scratch.

This takes us to:

	% rm -rf /tmp/pkg; (for i in {1..50}; do for j in {1..100}; do echo "package pkg { class A_${i}_${j}___(val a: Int, val b: Int) }"; done; done) > sandbox/A1.scala && time qbin/scalac -Ybackend:GenASM -J-Xmx1G -J-XX:MaxPermSize=400M -d /tmp sandbox/A1.scala;

	real	0m19.639s  // head~1 was 0m35.662s
	user	0m41.683s  // head~1 was 0m58.275s
	sys	0m1.886s

In more detail, this commit:

  - Removes the unused `fingerprint` constructor parameter from
    scopes. This is a remnant from a previous optimization attempt
  - Leave only one constructor on Scope which creates an empty
    scope
  - Update the factory method, `newNestedScope`, to copy the hash
    table from the parent if it exists. We can rely on the invariant
    that `outer.hashTable != null || outer.size < MIN_HASH)`, so we
    don't need `if (size >= MIN_HASH) createHash()` anymore. This
    used to be needed in `Scope#<init>`, which accepted an aribitrary
    `initElems: ScopeEntry`.
  - Update subclasses and factories of `Scope` in runtime reflection
    to accomodate the change. Pleasingly, we could actually remove
    the override for `newNestedScope`.
  - Unit tests the functionality I'm touching
Fast path in Namer for methods without defaults

Either direct defaults, or directly inherited.

The avoids `addDefaultGetters` in most cases, and the expensive
duplication of trees therein.
Optimize enforcement of dependent method type restrictions

  - No need to check the result type, as dependent method types
    are now enabled unconditionally.
  - This also means we can only need to check methods with two or
    more parameter lists.
SI-8625 fix unreachability analysis for boolean expressions
Merge pull request #3782 from retronym/topic/opt-scope

Compiler optimizations for Scopes, checkDoubleDefs, Namer
Merge pull request #3794 from lrytz/t8625

SI-8625 fix unreachability analysis for boolean expressions
Merge pull request #3733 from retronym/topic/pr-3712-resubmit

SI-8475 Fix off by one in GroupedIterator when Streaming
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 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, `ptMatchesPatternType` which replaces
pattern type variables by wildcards, but leaves other abstract
types intact in the pattern type. (It also special cases Arrays).

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