SI-4767 Inline @inline final trait methods

A trait consists of an interface and an implementation class. From a
JVM perspective, a class that extends a trait will actually implement
the interface and unless it overrides the member, will get a forwarder
to the implementation class:

for:
```
  trait Foo { @inline final def foo(x: Int) = println(x) }
  class Baz extends Foo
```

Baz is compled down to:
```
  class Baz extends Object with Foo {
   @inline final def foo(x: Int): Unit = Foo$class.foo(FooImpl.this, x)
   ...
  }
```

Now, say we have:
```
  def bar(y: Foo) = y.foo(7)
```

The type of `Foo` is `interface Foo`. Thus there's no way for the
inliner to load the bytecode for foo. The first part of this patch
addresses this problem, by transforming the call to `y.foo(7)` to
`Foo$class.foo(y, 7)` if the foo method is final and @inline marked.

The second part is actually inlining the static call to `Foo$class.foo`.
Now, the trick is that the inliner actually expects the calls it
inlines to have an instance on which they're run. I relaxed the inline
conditions to include static calls and changed the inliner to generate
correct code for static calls. (the VerifyError was caused by this)

The third part was adapting the ICodeReader to be able to pick up the
code from implementation classes. I think the ICodeReader needs a real
maintainer, I was only after getting the test cases to pass, but there
are still some failures visible with -Ydebug -Ylog:inliner.

Finally, added a couple of tests using Greg's instrumented partest
addon, and it's awesome!

Thanks to @magarciaEPFL, @lrytz and @xeno-by for their help!

Mandatory review by @paulp if we're going to get this in 2.10.
WIP. Fixed fallout from trait inlining
WIP. Fixed infinite loop in inliner
WIP. More tweaks
WIP. Don't publish
Fixes backend crash due to incorrect consumedTypes

This started out as a compiler crash after Greg copied the
comprehension methods to List and made them final.

The culprit was the dead code elimination phase, which after
sweeping pieces of code was unable to restore the stack to its
original state, thus causing the ASM backend to crash notifying
the resulting bytecode is incorrect.

The dead code elimination phase uses the icode Instructions'
consumedTypes to determine what needs to be dropped from the
stack when an instruction is eliminated, but the consumedTypes
were only defined for a handful of instructions. So dce encountered
a DUP instruction for which it did not have consumedTypes defined
and did not restore the stack correctly.

The consumedTypes/producedTypes for icode instructions are
redundantly defined in 3 separate places:
 - Opcodes.scala (consumedTypes/producedTypes)
 - ICodeCheckers.scala (for checking icode)
 - TypeFlowAnalysis.scala (for computing types on the stack at each
program point)

Since the Opcodes types are the only ones visible outside, I suggest
we use them in ICodeCheckers.scala and TypeFlowAnalysis.scala too. But
we should make such changes after the release, as we're chilling out
by the lake with a glass of good wine: SI-6234

The relevant discussion around it can be found at:
https://groups.google.com/forum/?fromgroups#!topic/scala-internals/qcyTjk8euUI[1-25]

Many thanks to Paul for his help!

Review by @magarciaEPFL or @paulp.
WIP * more debugging on memberInfo *
WIP. TODO:Revert
SI-6248 Correct bytecode for box/unbox sequences

Even for semantically incorrect code, the closure elimination phase
continues to generate correct java bytecode.

The sequence in question:
```
   LOAD_LOCAL v1  // <= loads v1: Long onto the stack
   BOX LONG       // <= takes a Long, returns an Object
   UNBOX INT      // <= takes an Object, returns an Int
```

From a Scala perspective, this can't happen. But with aggresive inline,
there is a way to produce this code. It won't ever be executed directly
and if expressly called, should result in a runtime exception. But with
the closure elimination (better called copy propagation phase) this
code will result in an incorrect:
```
   LOAD_LOCAL v1
   BOX LONG
   LOAD_LOCAL v1  // <= an Int should be on the stack, but we get a
                  // 2-slot long
```