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.
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".
SI-8237 Avoid cyclic constraints when inferring hk type args

An `AppliedTypeVars` spawned from `HKTypeVar#applyArgs`
(necessarily) shares the same `TypeConstraints`.

But, we can have multiple ATVs based on a single HKTV floating
around during inference, and they can appear on both sides
of type relations. An example of this is traced out in
the enclosed test.

This commit avoids registering upper/lower bound constraints
when this is detected.

In the enclosed test, we end up with an empty set of constraints
for `?E`, which results in inference of Nothing, which is what
we expect.

I have also improved the printing of ATVs (to include the args)
and sharpened the log message when `solve` leaves type variables
instantiated to `NoType`, rather than some other type that doesn't
conform to the bounds. Both of these changes helped me to get
to the bottom of this ticket. The improved `ATV#toString` shows
up in some updated checkfiles.

The reported test has quite a checkered history:

  - in 2.10.0 it worked, but more by good luck than good planning
  - after the fix for SI-7226 / 221f52757aa6, it started crashing
  - from 3bd897ba0054f (a merge from 2.10.x just before 2.11.0-M1)
    we started getting a type inference failure, rather than a crash.
    "no type parameters for method exists [...] because cyclic
    instantiation".
  - It still crashes in `isGround` in 2.10.3.
SI-8154 AnyRefMap iterates its way to ((null, null))

Changed logic to prevent mutation between hasNext and next from delivering invalid results.

Also fixed superscripts in scaladoc.
Optimization: use AnyRef map for Namer -> Typer tree handoff

And uses a map per-compilation unit, rather than one per Typer.

One small change required: we now need to clear this map in the
the interactive compiler which reuses compilation units, rather
than in the call to `Typer#reset`.
Optimation: use AnyRefMap in GenASM javaName caches

These are a hotspot in the backend.
Merge pull request #3371 from Ichoran/issue/8154

 AnyRefMap iterates its way to ((null, null))