brings JavaMirrors up to speed with ClassfileParser

Apparently there are still discrepancies between how the vanilla compiler
turns class files into symbols and how the reflective compiler does it.

Working on bringing these guys in sync, one bug at a time.
SI-4907 SI-4615 scala.bat honors -J and -D options.

This makes scala.bat parse and use -J and -D arguments.

Specifically:
 - Parameters starting with -J are stripped of the prefix, unquoted if
   necessary and appended to %JAVA_OPTS% or default values.
 - Parameters starting with -D are unquoted if necessary and then
   appended to the others. The right-hand side of a property can be
   quoted or not.
 - All of those are given to `java` before any other parameters.
 - The above only happens on parameter preceding the first parameter
   that does not start with "-" (usually a class name).
 - The exact arguments passed to scala.bat are also given as-is to
   the scala launcher (including -J and -D arguments).

   set JAVA_OPTS=-Xmx512m
   scala -J-Xmx128m -Dprop1=42 -Dprop2="hello world" "-Dprop3=bar"
"-J-Xms64m" Test foo

   will result in

   java -Xmx512m -Xmx128m -Dprop1=42 -Dprop2="hello world" -Dprop3=bar
-Xms64m [cp, scala main] -J-Xmx128m -Dprop1=42 -Dprop2="hello world"
"-Dprop3=bar" "-J-Xms64m" Test foo
Merge pull request #2761 from scalamacros/ticket/7510

Assorted toolbox fixes
Merge pull request #2767 from gourlaysama/t4907

SI-4907 SI-4615 scala.bat now honors -J and -D options.
SI-7331 tb.parse returns unpositioned trees

This commit gets rid off code wrapping that was previously used by
toolbox to get into correct parsing mode. Instead combination of
templateStats/accept(EOF) is used. This is the same solution as the one
used in repl and built-in scriptRunner

This pull request doesn't attempt to generalize this approach in any
way and re-use it all over the place due to the caution of possible
accidental compatibility breakage. I plan to do it separately against
master.

Additionally there are a few more changes that make importers be aware
of positions and a test for that (via @jedesah).
Merge pull request #2800 from densh/topic/toolbox-positions

SI-7331 tb.parse returns unpositioned trees
warn about uninitialized reads (in constructors), self-contained check

The check in question relies on helper maps and methods that don't
belong outside that check. This commit encapsulates those helpers into
the newly added `checkUninitializedReads()` , thus uncluttering
`transformClassTemplate()`
handling AnyVal special case early on to simplify logic afterwards

This way the contract of `transformClassTemplate()` can focus on
non-AnyVal cases, which are more regular from the perspective of
transforming their templates in the constructors phase.
how stuff works: elision of param-accessor-fields and outer-accessors
eliding what the constructor phase elides but with less effort (1 of 2)

For now both old and new implementations of elision coexist,
allowing cross-checking their results.
In the next commit only the new one will remain.
eliding what the constructor phase elides but with less effort (2 of 2)

Removing the old implementation of elision in constructors
in favor of the new one which is both faster, more readable.
method transformClassTemplate() turned into class TemplateTransformer

Before this commit, each activation of transformClassTemplate()
performed the rewriting that the constructors phase is well-known for.
Lots of auxialiary objects were created in the process,
with lifetime confined to said activation.

The same auxiliary objects (having same lifetimes as before)
also are in effect starting with this commit,
but now it's an instance of TemplateTransformer
that holds them together. In other words,
there's a one-to-one correspondence between:
- (what used to be) transformClassTemplate() activation
- TemplateTransformer initialization

After initialization, the result of TemplateTransformer
can be found in its `transformed` member val.

In fact, the refactoring to get here from the previous commit
basically involves taking the body of method transformClassTemplate()
as-is to become the template of TemplateTransformer.

The TemplateTransformer in question will allow modularizing
sub-transformations (e.g., DelayedInit) into dedicated traits
(see  upcoming commits).
separation of concerns: delayed-init in constructors

This commit modularizes TemplateTransformer by moving a few methods
from TemplateTransformer into the newly added DelayedInitHelper.

The methods in question
- delayedInitCall()
- delayedInitClosure()
- delayedEndpointDef()

build trees that rewriteDelayedInit() puts together.
That way, all trace of rewriting related to delayed-init
have vanished from TemplateTransformer and are encapsulated in
DelayedInitHelper.
separation of concerns: eliding param-accessor fields in constructors

This commit modularizes TemplateTransformer by moving a few members
from TemplateTransformer into the newly added OmittablesHelper.

The members in question include

- a few methods:
  # isParamCandidateForElision(Symbol)
  # isOuterCandidateForElision(Symbol)
  # mustbeKept(Symbol)

- a few vals:
  # paramCandidatesForElision
  # outerCandidatesForElision
  # bodyOfOuterAccessor

- class UsagesDetector

That way, all trace of rewriting to elide param-accessor fields
has vanished from TemplateTransformer and is encapsulated in
OmittablesHelper.
readability for intoConstructors transformer
better encapsulation in constructors phase
separation of concerns: guard non-specialized ctor-stats in constructors

This commit modularizes TemplateTransformer by moving two methods
from TemplateTransformer into the newly added OmittablesHelper.

The methods in question are:
- mergeConstructors(genericClazz, originalStats, specializedStats)
- guardSpecializedInitializer(stats)

That way, the rewriting that introduces a guard for the execution of
non-specialized ctor-statements is encapsulated in
trait GuardianOfCtorStmts.
skipping trips to specializeTypes when not necessary in constructors
Golfed about 20 lines into the sand trap.

And it's a nice golf clinic and all, but let's remove our
golf gloves and take in some film.

  for (stat <- defBuf.iterator ++ auxConstructorBuf.iterator)

A quick count:

 - defBuf is a ListBuffer (1 mutant)
 - auxConstructorBuf is a ListBuffer (2 mutants)
 - two mutable iterators over mutable sequences (3, 4 mutants)
 - Iterator.++ joins them and is BY-NAME (4 mutants, 1 tragedy in waiting)
 - the joined Iterator is a new mutable structure (5 mutants, now 3 deep)
 - omittables is a mutable Set (6 mutants)
 - the 5-layer-3-deep iterator mutates omittables as it walks

[The following is a public service breakdown. The letter
sequence y-o-u is a local variable which should be replaced
with your name, whoever "you" are, if you commit any code in
these parts.]

Hear my plea! YOU DON'T HAVE TO DO IT THIS WAY! It isn't simpler,
faster, easier, more satisfying, shorter, more pixelated, there
just isn't any advantage to it, even if you're lazy! Especially
if you're lazy! Whatever combination of virtues and vices exist
in your personal petri dish, this will never be a hilltop!

PLEASE COME ENJOY A DRINK WITH ME AND MY FRIEND 'VAL' !!
I'LL INTRODUCE YOU! I THINK YOU WILL REALLY LIKE HER! I HOPE
YOU WILL SEE A LOT OF ONE ANOTHER! REMEMBER THAT NAME, 'VAL' !!
SHE'LL HAVE HER EYE OUT FOR YOU!
showRaw now prints symbols of def trees

A very useful addition that came in handy when hacking macro annotations