Almost-fix for SI-3452.

At this commit ant test-opt has two test failures:

  test/files/pos/javaReadsSigs [FAILED]
  test/files/run/t4238 [FAILED]

Fix for wrong bytecode in forwarders.

This took me so long to figure out I can't even tell you. Partly because
there were two different bugs, one which only arose for trait forwarders
and one for mirror class forwarders, and every time I'd make one set
of tests work another set would start failing. The runtime failures
associated with these bugs were fairly well hidden because you usually
have to go through java to encounter them: scala doesn't pay that much
attention to generic signatures, so they can be wrong and scala might still
generate correct code. But java is not so lucky.

Bug #1)

During mixin composition, classes which extend traits receive forwarders
to the implementations. An attempt was made to give these the correct
info (in method "cloneBeforeErasure") but it was prone to giving
the wrong answer, because: the key attribute which the forwarder
must capture is what the underlying method will erase to *where the
implementation is*, not how it appears to the class which contains it.
That means the signature of the forwarder must be no more precise than
the signature of the inherited implementation unless additional measures
will be taken.

This subtle difference will put on an unsubtle show for you in test
run/t3452.scala.

  trait C[T]
  trait Search[M] { def search(input: M): C[Int] = null }
  object StringSearch extends Search[String] { }
  StringSearch.search("test");  // java
  // java.lang.NoSuchMethodError: StringSearch.search(Ljava/lang/String;)LC;

Before/after this commit:

  <   signature                                search  (Ljava/lang/String;)LC<Ljava/lang/Object;>;
  ---
  >   signature                                search  (Ljava/lang/Object;)LC<Ljava/lang/Object;>;

Bug #2) The same principle is at work, at a different location.
During genjvm, objects without declared companion classes
are given static forwarders in the corresponding class, e.g.

  object Foo { def bar = 5 }

which creates these classes (taking minor liberties):

  class Foo$ { static val MODULE$ = new Foo$ ; def bar = 5 }
  class Foo  { static def bar = Foo$.MODULE$.bar }

In generating these, genjvm circumvented the usual process whereby one
creates a symbol and gives it an info, preferring to target the bytecode
directly. However generic signatures are calculated from symbol info
(in this case reusing the info from the module class.) Lacking even the
attempt which was being made in mixin to "clone before erasure", we
would have runtime failures of this kind:

  abstract class Foo {
    type T
    def f(x: T): List[T] = List()
  }
  object Bar extends Foo { type T = String }
  Bar.f("");    // java
  // java.lang.NoSuchMethodError: Bar.f(Ljava/lang/String;)Lscala/collection/immutable/List;

Before/after this commit:

<   signature                                     f  (Ljava/lang/String;)Lscala/collection/immutable/List<Ljava/lang/String;>;
---
>   signature                                     f  (Ljava/lang/Object;)Lscala/collection/immutable/List<Ljava/lang/Object;>;

Closes SI-3452.
WIP
WIP Selectively weakened Java generic signatures in mixin
WIP
Stability of test output.
WIP
SI-3452 light at the end of the tunnel

  - Mixin adds a bridges if the mixed in method has a sharper
    type than the overriden method.