updating resolveDups() to use MethodTFA.mutatingInterpret()
SI-6175 reflect over classes with symbolic names

Top-level classes with symbolic names (having binary names like $colon$colon)
have previously been incorrectly treated as local classes by Scala reflection.
As a result they were loaded as if they weren't pickled (i.e. as Java classes).

Moreover this bug also had a more subtle, but more dangerous manifestation.
If such a class has already been loaded indirectly by unpickling another class
(which refers to it in its pickle) and then someone tried to load it explicitly
via classToScala, then it would be loaded twice (once as a Scala artifact and
once as a Java artifact). This is a short route to ambiguities and crashes.

The fix first checks whether a class with a suspicious name (having dollars)
can be loaded as a Scala artifact (by looking it up in a symbol table).
If this fails, the class is then loaded in Java style (as it was done before).

Ambiguous names that can be interpreted both ways (e.g. foo_$colon$colon)
are first resolved as Scala and then as Java. This prioritization cannot lead
to errors, because Scala and Java artifacts with the same name cannot coexist,
therefore loading a Scala artifact won't shadow a homonymous Java artifact.
Basing Futures on Try instead of Either
SI-6185 - add "prepare" hook to ExecutionContext

Enables important abstractions to be built on top of futures,
such as Twitter's "Local" for handling data local to a callback chain.
Temporarily skips failing test due to optimizer bug SI-6188

Also swaps the arguments to method transform on Try, so as to mirror transform on scala.concurrent.Future.
Merge branch 'try-based-futures' of https://github.com/heathermiller/scala into try-based-futures
adds deprecation annotations on manifest incantations
SI-6188 ICodeReader notes exception handlers, Inliner takes them into account
Merge pull request #1045 from scalamacros/ticket/6175

SI-6175 reflect over classes with symbolic names
better error messages for Symbol.asXXX methods
adds more tests for api.Symbols

I overlooked some of the tests that should be added to the public API.
This commit fixes my mistake. Also see 027b00171c.

To reiterate the reasoning behind introduction of test methods into the API.
I'd argue that the API duplication w.r.t flags is trumped by unified interface
to tests and better encapsulation (especially since some of the flags have
different meaning depending on whether the flaggee is a term or a type).
compatibility stub for SBT 0.12.0

As discussed in http://groups.google.com/group/scala-internals/browse_thread/thread/9ee8df2ae9d43169,
recent change of return type for Type.members (from List[Symbol] to Scope)
broke compiler-interface for SBT 0.12.0-final.

This stub (courtesy of Jason Zaugg) keeps reflection API untouched and
also fixes SBT. Win-win.
SI-6157 don't inline callee with exception-handler(s) if potentially unsafe
SBT compiler interface now compiled in ant build.  Ensures those still using ant don't break the interface.
Merge pull request #1047 from scalamacros/topic/moar-symbol-tests

adds more tests for api.Symbols
Merge pull request #1055 from scalamacros/topic/deprecate-manifest-incantations

adds deprecation annotations on manifest incantations
Merge pull request #1061 from scalamacros/topic/sbt-compat

compatibility stub for SBT 0.12.0
SI-5788 Tailcalls LabelDefs correctly duplicated

... in specialization.

This is a quick hack to get SI-5788 fixed in 2.10.x. The full patch,
which fixes the tailcalls LabelDefs will be merged into trunk, as it's
too late for big changes.

For reference, the complete fix is: e86afe65c8
SI-6102 avoid emitting illegal exception table range
test case for SI-6102