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
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
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 #3487 from andy128k/master

fix typo
SI-6260 Avoid double-def error with lambdas over value classes

Post-erasure of value classs in method signatures to the underlying
type wreaks havoc when the erased signature overlaps with the
generic signature from an overriden method. There just isn't room
for both. But we *really* need both; callers to the interface method
will be passing boxed values that the bridge needs to unbox and
pass to the specific method that accepts unboxed values.

This most commonly turns up with value classes that erase to
Object that are used as the parameter or the return type of
an anonymous function.

This was thought to have been intractable, unless we chose
a different name for the unboxed, specific method in the
subclass. But that sounds like a big task that would require
call-site rewriting, ala specialization.

But there is an important special case in which we don't need
to rewrite call sites. If the class defining the method is
anonymous, there is actually no need for the unboxed method;
it will *only* ever be called via the generic method.

I came to this realisation when looking at how Java 8 lambdas
are handled. I was expecting bridge methods, but found none.
The lambda body is placed directly in a method exactly matching
the generic signature.

This commit detects the clash between bridge and target,
and recovers for anonymous classes by mangling the name
of the target method's symbol. This is used as the bytecode
name. The generic bridge forward to that, as before, with
the requisite box/unbox operations.
SI-6260 Adddress pull request review

  - fix typo
  - remove BRIDGE flag from the method that we promote from
    a bridge to a bona-fide method
  - note possibility for delambdafy to avoid the bridge method
    creation in *all* cases.
  - note inconsistency with anonymous class naming between
    `-Ydelamdafy:{inline,method}`
Merge pull request #3409 from xeno-by/ticket/6411

SI-6411 SI-7328 value class fixes for runtime reflection
Merge pull request #3406 from xeno-by/ticket/7570

SI-7570 top-level codegen for toolboxes
Merge pull request #3428 from retronym/ticket/6260

SI-6260 Avoid double-def error with lambdas over value classes
Merge pull request #3494 from retronym/topic/opt-any-ref-map

Optimization: use AnyRef map for Namer -> Typer tree handoff
Merge pull request #3496 from adriaanm/t6169

SI-6169 TODO: consolidate with fix for SI-1786 (#2518)
Merge pull request #3480 from paulp/pr/publicize-abstract-star

 Make the Abstract* classes public.
SI-8219 Pending test case for unpositioned implicit error

Extracted with tweezers from ScalaTest and Scalacheck implicits.

    % scalac-hash v2.11.0-M7 test/pending/pos/t8219.scala
    error: type mismatch;
     found   : Any
     required: AnyRef
    Note: Any is not implicitly converted to AnyRef.  You can safely
    pattern match `x: AnyRef` or cast `x.asInstanceOf[AnyRef]` to do so.
    error: type mismatch;
     found   : Any
     required: AnyRef
    Note: Any is not implicitly converted to AnyRef.  You can safely
    pattern match `x: AnyRef` or cast `x.asInstanceOf[AnyRef]` to do so.
    two errors found