SI-7570 top-level codegen for toolboxes

Provides a way to inject top-level classes, traits and modules into
toolbox universes.

Previously that was impossible, because compile and eval both wrap their
arguments into an enclosing method of a synthetic module, which makes it
impossible to later on refer to any definitions from the outside.
SI-6411 reflection is now aware of posterasure

The `transformedType` method, which is used to bring Scala types to Java
world, was written in pre-valueclass times. Therefore, this method only
called transforms from erasure, uncurry and refChecks.

Now runtime reflection becomes aware of posterasure and as a consequence
methods, which have value classes in their signatures, can be called
without having to wrap them in catch-a-crash clause.

Another facet to this fix was the realization that value classes need
to be unwrapped, e.g. C(2) needs to be transformed to just 2, when they
are used naked in method signatures (i.e. `c` in `def foo(c: C)` needs
to be unwrapped, whereas `cs: List[C]`, `cs: C*` and even `cs: Array[C]`
do not).
updates the test for by-name value class parameters
unifies method and constructor handling in JavaMirrors

This automatically brings performance fixes and correct handling of
values class / by-name params into the constructor land.
SI-7328 FieldMirrors now support value classes
SI-7933 REPL javax.script eval is cached result

The problem is that the repl underneath the script engine evaluates input to
val res0..resN, so it is a one shot operation. To allow repetition,
compile(script) now returns a CompiledScript object whose eval method can be
called any number of times.
SI-8215: Correcting typo and splitting a long sentence in MatchIterator doc

Follow-up to 9c0ca62
SI-6169 Refine java wildcard bounds using corresponding tparam

Also fixes part of SI-8197. Necessary complement to SI-1786 (#2518),
because we now infer tighter bounds for RHSs to conform to.

When opening an existential, Java puts constraints in the typing environment
that are derived from the bounds on the type parameters of the existentially
quantified type, so let's do the same for existentials over java-defined
classes in skolemizeExistential...

Example from test case:

```
public class Exist<T extends String> {
  // java helpfully re-interprets Exist<?> as Exist<? extends String>
  public Exist<?> foo() { throw new RuntimeException(); }
}
```

In Scala syntax, given a java-defined `class C[T <: String]`, the
existential type `C[_]` is improved to `C[_ <: String]` before skolemization,
which models what Java does (track the bounds as type constraints in the typing environment)

(Also tried doing this once during class file parsing or
when creating the existential type, but that causes cyclic errors
because it happens too early.)
SI-6169 more accurate check for raw java type encoded as existential
SI-6169 initialize before .typeParams -- just in case
SI-8207 Allow import qualified by self reference

This regressed in SI-6815 / #2374. We check if the result of
`typedQualifier(Ident(selfReference))` is a stable identifier
pattern. But we actually see the expansion to `C.this`, which
doesn't qualify.

This commit adds a special cases to `importSig` to compensate.
This is safe enough, because the syntax prevents the following:

	scala> class C { import C.this.toString }
	<console>:1: error: '.' expected but '}' found.
	       class C { import C.this.toString }
	                                        ^
So loosening the check here doesn't admit invalid programs.
I've backed this up with a `neg` test.

The enclosed test also checks that we can use the self
reference in a singleton type, and as a qualifier in
a type selection (These weren't actually broken.)

Maybe it would be more principled to avoid expanding the self
reference in `typedIdent`. I can imagine that the current situation
is a pain for refactoring tools that try to implement a rename
refactoring, for example.

Seems a bit risky at the minute, but I've noted the idea
in a comment.
addresses pull request feedback
SI-6948 Make the Abstract* classes public.

Several weaknesses in the implementation converge and force multiply.

1) Type constructor inference is not persistent. During implicit search
it will give up after the first seen parent even if some deeper base type
(even another direct parent) would satisfy the search.

2) Type inference is not aware of access restrictions. Inferred types are
calculated with disregard for whether the inferred type is visible at
the point of inference. That means that package-private types - which may be
private for any number of good reasons, such as not wanting them to appear in
bytecode thus creating binary compatibility obligations - are not private.
There is no such thing as a qualified private type.

  package p {
    trait PublicInterface[T] { def foo(): Int }
    private[p] trait ImplementationOnly[T] extends PublicInterface[T] { def foo(): Int = 1 }
    class PublicClass extends ImplementationOnly[PublicClass]
  }
  package q {
    object Test {
      def f[A, CC[X]](xs: CC[A]): CC[A] = xs
      def g = f(new p.PublicClass) // inferred type: p.ImplementationOnly[p.PublicClass]
      def h = g.foo()
      // Bytecode contains:
      // public p.ImplementationOnly<p.PublicClass> g();
      // public int h();
      //    0: aload_0
      //    1: invokevirtual #30                 // Method g:()Lp/ImplementationOnly;
      //    4: invokeinterface #33,  1           // InterfaceMethod p/ImplementationOnly.foo:()I
      //    9: ireturn
    }
  }

3) The trait encoding leads to a proliferation of forwarder methods, so much so that
1.5 Mb of bytecode was taken off of the standard library size by creating abstract classes
which act as central mixin points so that leaf classes can inherit some methods the
old fashioned way rather than each receiving their own copy of every trait defined method.
This was done for 2.10 through the creation of the Abstract* classes, all of which were
given reduced visibility to keep them out of the API.

  private[collection] class AbstractSeq extends ...

This achieved its intended goal very nicely, but also some unintended ones.

In combination with 1) above:

  scala> val rand = new scala.util.Random()
  rand: scala.util.Random = scala.util.Random@7f85a53b

  // this works
  scala> rand.shuffle(0 to 5)
  res1: scala.collection.immutable.IndexedSeq[Int] = Vector(4, 0, 1, 2, 5, 3)

  // and this doesn't! good luck reasoning that one out
  scala> rand.shuffle(0 until 5)
  <console>:9: error: Cannot construct a collection of type scala.collection.AbstractSeq[Int]
    with elements of type Int based on a collection of type scala.collection.AbstractSeq[Int].
                rand.shuffle(0 until 5)
                            ^

  // Somewhat comically, in scala 2.9 it was flipped: to failed (differently), until worked.
  scala> scala.util.Random.shuffle(0 to 5)
  <console>:8: error: type mismatch;
   found   : scala.collection.immutable.Range.Inclusive
   required: ?CC[?T]

  scala> scala.util.Random.shuffle(0 until 5)
  res2: scala.collection.immutable.IndexedSeq[Int] = Vector(4, 3, 1, 2, 0)

In combination with 2) above:

  scala> def f[A, CC[X]](xs: CC[A]): CC[A] = xs
  f: [A, CC[X]](xs: CC[A])CC[A]

  scala> var x = f(1 until 10)
  x: scala.collection.AbstractSeq[Int] = Range(1, 2, 3, 4, 5, 6, 7, 8, 9)

  // It has inferred a type for our value which it will not allow us to use or even to reference.
  scala> var y: scala.collection.AbstractSeq[Int] = x
  <console>:10: error: class AbstractSeq in package collection cannot be accessed in package collection
         var y: scala.collection.AbstractSeq[Int] = x
                                 ^
  // This one is a straight regression - in scala 2.9,
  scala> var x = f(1 until 10)
  x: scala.collection.immutable.IndexedSeq[Int] = Range(1, 2, 3, 4, 5, 6, 7, 8, 9)

Since 1) and 2) are essentially unfixable - at least by me - I propose
to ameliorate these regressions by attacking the symptoms at the leaves.
That means making all the Abstract* classes public - keeping in mind that
they must already be assumed to be in the binary compatibility footprint,
since they have been leaking throughout their existence. This only impacts
the inference of inaccessible collections types - it doesn't help with the
more serious issue with type inference.
further limits discoverability of resetAttrs

This commit removes resetAllAttrs from the public reflection API.
This method was previously deprecated, but on a second thought that
doesn't do it justice. People should be aware that resetAllAttrs is just
wrong, and if they have code that uses it, this code should be rewritten
immediately without beating around the bush with deprecations. There's
a source-compatible way of achieving that (resetLocalAttrs), so that
shouldn't bring much trouble.

Secondly, resetAllAttrs in compiler internals becomes deprecated. In subsequent
commits I'm going to rewrite the only two locations in the compiler that
uses it, and then I think we can remove it from the compiler as well.
does away with resetAllAttrs in the reifier

resetLocalAttrs works just fine there
does away with resetAllAttrs in typedLabelDef

Again, resetLocalAttrs works just fine there - no need to destroy
references to externally defined symbols.
SI-8248 kills resetAllAttrs

Noone uses it anymore, so I'm rushing to remove it, so that it no longer
can trick people into using it.
renames resetLocalAttrs to resetAttrs

Now when resetAllAttrs is gone, we can use a shorter name for the one
and only resetLocalAttrs.
fix typo
SI-8245 Fix regression in interplay between lazy val, return

In 4c86dbbc492 / SI-6358, synthesis of lazy val accessors trees was
moved into the typer phase (in MethodSynthesis). Before that point,
the symobl for the accessor *was* created early, but the tree was
not. This led to crashes in intervening phases (extensionmethods)
as `changeOwner` calls didn't catch the smuggled symbol.

Moving the accessor generation forward, however, brought a problem:
we now introduce a DefDef around the RHS of the lazy val, but we're
not actually guaranteed that the body has already been typechecked.
If it happened to be typechecked for the purposes of return type
inference, we'll pick up the typechecked tree from `transformed`:

    // LazyValGetter#derivedTree
    val rhs1 = transformed.getOrElse(rhs0, rhs0)

But if the method had an explicit return type (which must *always*
be the case if it contains a `return`!), `rhs0` will be untyped.

This leads to, e.g.:

    def foo(o: Option[Int]): Int = {
      lazy val i = o.getOrElse(return -1)
      i + 1
    }

    def foo(o: Option[Int]): Int = {
      lazy <artifact> var i$lzy: Int = _;
      <stable> <accessor> lazy def i: Int = {
        i$lzy = o.getOrElse(return -1);
        i$lzy
      };
      i.+(1)
    };

When this is typechecked, the `return` binds to the closest enclosing
`DefDef`, `lazy def i`. This commit changes `Context#enclMethod` to
treat `DefDef`s as transparent.

`enclMethod` is only used in one other spot that enforces the
implementation restriction that "module extending its companion class
cannot use default constructor arguments".