SI-5652 Mangle names of potentially public lambda lifted methods.

This can happen if they are accessed from an inner class. If a
subclass is happens to lift a public method to the same name,
a VerifyError ensues.

The enclosed tests:
 - demonstrate the absense of the VerifyError
 - show the names generated for the lifted methods (which are
   unchanged if not called from an inner class, or if lifted
   into a trait implementation class.)
 - ensure that the callers are rewritten to call the correct
   method when multiple with the same name are lifted.

It's not ideal that this phase needs a priori knowledge of the
later phases to perform this mangling. A better fix would defer
this until the point when the methods are publicised, and leave
the unmangled private method in place and install an public,
mangled forwarder.
GenASM-based fix for SI-4804. Fix of the same for GenJVM pending.
SI-5167 An impl class method should refer to its own parameter symbols.

Rather than those of the original method in the trait.

If they are shared, parameter renaming in the implementaion class
is visible in the original method. This led to a crash in the resident
compiler when looking up the default argument getter.
Fixes SI-5857.

Override `min` and `max` in `Range` and `NumericRange`
to check if a default `Ordering` for the numeric type
in question is used.
If so, bypass traversal and compute the minimum or
maximum element.
counterpart in GenASM to 241c7606d0bf5f3209b9d549fb75
Fix SI-5853.

This solves two issues.

First, up to now the newly generated symbols for normalized
members were not being added to the declaration list of the
owner during `specialize`. Now they are.

Second, during `extmethods`, the extension methods generated
get an additional curried parameter list for `$this`.
Trouble was, after that, during `uncurry` and before `specialize`,
these curried parameter lists were merged into one list.
Specialization afterwards treats extension methods just
like normal methods and generates new symbols without the
curried parameter list.
The `extensionMethod` now takes this into account by checking
if the first parameter of a potential extension method has
the name `$this`.

Review by @dragos.
Review by @odersky.
Merge pull request #678 from magarciaEPFL/fixes

counterpart in GenASM to 241c7606d0bf5f3209b9d549fb75
Merge pull request #654 from magarciaEPFL/ticket-SI-4804

GenASM-based fix for SI-4804. Fix of the same for GenJVM pending.
Merge pull request #672 from axel22/issue/5857

Fixes SI-5857. More efficient min and max in Range and NumericRange
typers: fixes error handling in checkStable
typers: dubious line in adaptType
typers: simplifies original calculation in typedAnnotated
REPL no longer hangs after initialization crashes
REPL bells and whistles: -Dscala.repl.autoruncode=<JFile>

Useful for the upcoming reflection refactoring.
Previously it was more or less okay to type "import scala.reflect.mirror._",
but soon we'll have multiple universes and mirrors.
REPL bells and whistles: -Dscala.repl.vids=<Boolean>

Displays identity hashcodes next to `res` values printed by REPL.
This proved quite useful in detecting reflection artifacts that look the same,
but are, in fact, different.
REPL bells and whistles: -Dscala.repl.maxprintstring=<Integer>

Makes `maxPrintString` configurable and fixes its treatment at zero.
Quite useful for debugging elaborate classloaders with long classpaths.
improves traces and error messages
macros: -Xmacros is now retired
macros: now use Java reflection

Due to some voodoo magic creating a new instance of a compiler cake,
immediately degrades performance of the compiler.

Out guess is that it makes HotSpot treat calls to cake methods as polymorphic.
However we didn't do any performance testing, it just works, and that's enough.
Enough for now.
macros: refactoring of fast track infrastructure

As a result, hardwired macros don't need implementation stubs.
This is very important, because in a few commits scala.reflect.makro.Context
will move out from scala-library.jar.

Also adding fast track entries doesn't require jumping through hoops
with PDTs. It's as simple as defining PartialFunction[Tree, Any].