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!
moves compileTimeOnly to scala-library

This is the notion that's come to be universally useful, so I suggest
we promote it to be universally accessible.

Note that the attached test incorrectly fails to report errors for
definitions coming from the empty package and for annotations. These
are bugs, and they are fixed in subsequent commits of this pull request.
marks Expr.splice and Expr.value with @compileTimeOnly

Now that @compileTimeOnly is part of the standard library, why don't
we use it within the standard library.
@compileTimeOnly now works for annotations

http://docs.scala-lang.org/overviews/macros/annotations.html
say sincere "thank you!".
@compileTimeOnly now works for symbols from the empty package

Looks like we've got the entire language covered now.
SI-1980 A lint warning for by-name parameters in right assoc methods

The desugaring of right associative calls happens in the parser. This
eagerly evaluates the arguments (to preserve left-to-right evaluation
order the arguments are evaluated before the qualifier).

This is pretty surprising if the method being called has a by-name
parameter in the first parameter section.

This commit adds a warning under -Xlint when defining such a method.

The relevent spec snippets:

> SLS 4.6.1 says that call-by-name argument "is not evaluated at the point of function application, but instead is evaluated at each use within the function".
>
> But 6.12.3 offers:
> "If op is right- associative, the same operation is interpreted as { val x=e1; e2.op(x ) }, where x is a fresh name."
Use scala-partest 1.0-RC4

RC3 had a binary incompatibility that led to a crash in parsing options,
due to:
- https://github.com/scala/scala-partest/commit/9ff138ab4b
- https://github.com/scala/scala/commit/2b1563fa74

Also added sonatype as a repo for resolving partest,
so we don't have to wait for artifacts to synch to maven central.
Merge pull request #2862 from adriaanm/partest-1.0-RC4

Use scala-partest 1.0-RC4