SI-6725 `f` interpolator now supports %n tokens

Currently the `f` interpolator supports format specifiers which
specify conversions for formatted arguments. However Java formatting
is not limited to argument-related conversions as explained in:
http://docs.oracle.com/javase/6/docs/api/java/util/Formatter.html#detail.

Conversions which don't correspond to any arguments are `%` (used to
emit verbatim `'%'` characters) and `n` (used to emit platform-specific
line separators). Of those only the former is supported, and this patch
fixes the oversight.
SI-7132 - don't discard Unit type in interpreter
SI-7233 Account for aliased imports in eta expansion.

Buggy:

    treeCopy.Select(sel, sel.qual, sel.name) setSymbol null
    Select(sel, sel.qual, sel.name)

Okay:

    treeCopy.Select(sel, sel.qual, sel.name)
    Select(sel, sel.qual, sel.symbol.name) // but doesn't copyAttrs!

It is an easy mistake to make, I've found one more occurance:

  def foo(a: Any) = { import a.{toString => toS}; toS }

    error: uncaught exception during compilation: scala.reflect.internal.FatalError
    scala.reflect.internal.FatalError: class Object does not have a member toS
        at scala.reflect.internal.Definitions$DefinitionsClass.scala$reflect$internal$Definitions$DefinitionsClass$$fatalMissingSymbol(Definitions.scala:1028)

A followup commit will address that problem.
SI-7233 Account for aliased imports in Erasure

When we discard the fiction of `scala.Any`.
SI-7240 fixes language feature lookup

As I discovered today, Definitions.getMember have a fallback clause,
which accounts for the phases which have inner classes flattened.

This fallback uses nme.flattenedName to compute a flattened name, but
unfortunately nme.flattenedName produces a TermName, not a TypeName,
which means that the fallback will commence search in a wrong namespace
with predictable results.

The commit also changes another usage of nme.flattenedName in a type name
context. That one was correctly converting a TermName result to TypeName,
so this is not a bugfix, but just a refactoring for the sake of being
consistent.
Merge pull request #2227 from mergeconflict/2.10.x-SI-7132

SI-7132 - don't discard Unit type in interpreter
Merge pull request #2222 from scalamacros/ticket/6725

SI-6725 `f` interpolator now supports %n tokens
Merge pull request #2230 from retronym/ticket/7233

SI-7233 Account for aliased imports in EtaExpansion / Erasure
Merge pull request #2234 from scalamacros/ticket/7240

SI-7240 fixes language feature lookup
SI-7242 Fix crash when inner object mixes in its companion

Given:

    class C {
      trait T { C.this }            // C$T$$$outer$ : C
      object T extends T { C.this } // C$T$$$outer$ : C.this.type
    }

object T ended up with a definitions for both of the accessors.
These cannot co-exist, as they have the same erased type. A crash
ensued almost immediately in explitouter.

Fortunately, the solution is straightforward: we can just omit
the mixin outer accessor altogether, the objects own outer accessor
is compatible with it.

    scala> :javap C.T
    Compiled from "<console>"
    public interface C$T{
        public abstract C C$T$$$outer();
    }

    scala> :javap C.T$
    Compiled from "<console>"
    public class C$T$ extends java.lang.Object implements C$T{
        public C C$T$$$outer();
        public C$T$(C);
    }

I also added an assertion to give a better error message in
case we find ourselves here again.

Also includes tests from SI-3994, which I'll mark as a duplicate.
SI-6921 SI-7239 Tread lightly during exploratory typing

When deciding whether an Assign is a named argument or
and assignment expression, or when looking at arguments
that the current selection is applied to in order to
evaluate candidate implicit views, we risk polluting
the tree by setting error types. This happens even
if we are in 'silent' mode; that mode does silence the
error report, but not the side effect on the tree.

This commit adds strategic `duplicate` calls to
address the problem symptomatically.

Duplicating trees and retyping in general reach into
the domain of bugs umbrella-ed under SI-5464, but in
these places we should be safe because the tree is in
the argument position, not somewhere where, for example,
a case class-es synthetic companion object might be
twice entered into the same scope.

Longer term, we'd like to make type checking side effect
free, so we wouldn't need to play whack-a-mole like this.
That idea is tracked under SI-7176.
SI-7232 Fix Java import vs defn. binding precendence

Java Spec:
> A single-type-import declaration d in a compilation unit c
> of package p that imports a type named n shadows, throughout
> c, the declarations of:
>   - any top level type named n declared in another compilation
>     unit of p
>   - any type named n imported by a type-import-on-demand
>     declaration in c
>   - any type named n imported by a static-import-on-demand
>     declaration in c

Scala Spec:
> Bindings of different kinds have a precedence deﬁned on them:
>   1. Deﬁnitions and declarations that are local, inherited, or made
>      available by a package clause in the same compilation unit where
>      the deﬁnition occurs have highest precedence.
>   2. Explicit imports have next highest precedence.
SI-7249 Reign in overzealous Function0 optimization.

The fix for SI-1247 went too far, and could result in
premature evaluation of the expression that yields the
Function0.

This commit checks that said expression is safe to inline.
If not, a wrapper `() => ....` is still required.

The optimization is still enabled in sitations like the
original test case, run/t1247.scala.
Read version 51 (JDK 7) class files.

This commit makes the ClassFileReader/ICodeReader parse class files
from JDK 7 (class file version 51). It does that by skipping over
the method handle related entries in the constant pool and by doing
some dummy processing on invoke dynamic instructions. The inliner
is updated to not try to inline a method with an invoke dynamic
instruction. A place holder INVOKE_DYNAMIC instruction is added to ICode
but it is designed to create an error if there's ever any attempt to
analyze it. Because the inliner is the only phase that ever tries
to analyze ICode instructions not generated from Scala source and
because Scala source will never emit an INVOKE_DYNAMIC, the place
holder INVOKE_DYNAMIC should never cause any errors.

A test is included that generates a class file with INVOKE_DYNAMIC
and then compiles Scala code that depends on it.
SI-6123: -explaintypes should not explain errors which won't be reported

-explainTypes means that only type tests which *fail* should be reported in more
detail by using explainTypes. Hence, callers of explainTypes should check if
type errors are being ignored, by checking context.reportErrors. Hence, this
check is added to Inferencer, and another call site is redirected to that
method.

Moreover, explainTypes should only be called if an error exists. Enforce that in
checkSubType, and remove spurious home-made explainTypes output.

Finally, in ContextErrors, stop checking `settings.explaintypes.value` before
calling `explainTypes` which will check it again.

Note that this patch does not fix all occurrences, but only the ones which
showed up during debugging. The other ones never cause problems, maybe because
they occur when contextErrors is in fact guaranteed to be true. We might want to
fix those ones anyway.

This fixes regressions in c800d1fec5241ed8c29e5af30465856f9b583246 and
78f9ef3906c78413ff8835fdad3849bfe5516be2.

Thanks to hubertp (Hubert Plociniczak) for the first round of review.

Refs #6123
backport to _2.10.x_
Add positive and negative testcases for SI-6123 (-explaintypes)

Positive testcases compile reduced known offenders to verify that no output is
produced.

The negative testcase tests that -explaintypes actually produces output on code which fails
to compile. I have altered an existing testcase, `test/files/neg/abstract`,
adding -explaintypes to the flags.

This testcase is currently mostly ineffective, as partest currently ignores the
standard output (SI-7003). It will become more effective when SI-7003 is fixed.
But already now, testers would at least be able to notice extraneous output.

This argument is somewhat bogus, but this patch is no worse than the other ones
which are committed while SI-7003 is open.
[backport] SI-7237 Always choose ForkJoinTaskSupport

... on Java 6 and above.

ForkJoinTaskSupport works on Hotspot, Avian and J9,
while ThreadPoolTaskSupport causes the test
test/files/scalacheck/parallel-collections
to reliably hang on all three.

We keep ThreadPoolTaskSupport around to keep the hope
alive that we still have a glimpse of 1.5 support.
SI-7258 Don't assume order of reflection values in t6223

test/files/run/t6223's check file expects a specific
ordering of the reflected values. The ordering is not
guaranteed by the runtime/reflection API and can change.

Therefore, sort the values before comparing them.
SI-7253: respect binary compatibility constraints

From the JLS one can prove that moving a method to a superclass is a binary
compatible change, both forward and backward. That's because when compiling a
method call `c.foo()`, where c: C, the output descriptor *must* refer to `C` and
not to the class where `foo()` is actually defined.

This patch just ensures that, and adds a test comparing generated descriptors
against the Javac output.

The sample code is from Paul Philipps, the fix and the bytecode comparison code
from me.

From 2006 (9954eafffd5e60676238369ab0ed5797c92b4a7b, a fix for bug 455 in the
old bug tracker
http://www.scala-lang.org/sites/default/files/aladdin/displayItem.do%3Fid=455.html)
until 2.9, Scalac has followed this rule "often" (that is, when C is *not* an
interface).

This behavior was wrong, but the bug was hard to trigger. AFAICS, this can
create problems only when moving a method to a super interface in a library and
expecting forward binary compatibility - that is, compiling some Scala client
code against the new version of the library, and trying to run this code against
the old version of the library. This change grows an interface, so it is valid
only if clients are supposed to *not* implement the library.  Apparently, this
is so rare that nobody noticed.

Since 2.10 (0bea2ab5f6b211a83bbf14ea46fe57b8163c6334), Scalac follows this rule
*only* when C is an interface (I assume by oversight, since the main change was
an accessibility check), so the bug was finally triggered.

The new code will have to emit INVOKEINTERFACE instead of INVOKEVIRTUAL a bit
more often, compared to 2.9 (but not to 2.10). I don't know whether
INVOKEINTERFACE is noticeably slower (it shouldn't be); but this is the safest
fix since this behavior is mandated by the JLS.
If somebody disagrees and believes the 2.9 is significantly faster, IMHO he
should send a separate pull request (although ProGuard is probably a better
place for the change).
Remove fragile code, made redundant by previous commit

The JLS requires, as an exception to generate calls referring to Object for all
methods defined in Object itself; hence, whenever the method owner is Object,
the call should refer to the method owner. The previous commit implemented this
directly in useMethodOwner, so the special case for Object in isInterfaceCall is
now redudant. Hence, remove it.