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!
ProcessBuilder.lines(log) *does* throw an exception.
Fix typo in sample code in scaladoc for package scala.sys.process
Merge pull request #2805 from adriaanm/rebase-2715

Constructors refactoring [Rebase of #2715]
Merge pull request #2858 from Debilski/docstring-fix

ProcessBuilder.lines(log) *does* throw an exception.
Merge pull request #2867 from mmorearty/patch-1

Fix typo in sample code in scaladoc for package scala.sys.process