SI-7509 Avoid crasher as erronous args flow through NamesDefaults

The fix for SI-7238 caused this regression.

This commit marks taints whole Apply with an ErrorType if it
has an erroneous argument, so as to stop a later crash trying
to further process the tree.
Merge pull request #2588 from retronym/ticket/7509

SI-7509 Avoid crasher as erronous args flow through NamesDefaults
Temporary reversion of a bit of d8b96bb858.

If I reverse these few lines, I can rebase miguel's
pull request cleanly; if I don't, git thinks there are
enough merge conflicts to start a war. Something is
suboptimal in that algorithm.
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
separation of concerns: delayed-init in constructors
separation of concerns: elision in constructors
readability for intoConstructors transformer
separation of concerns: guard non-specialized ctor-stats in constructors
skipping trips to specializeTypes when not necessary in constructors
Reversing reversion of ac6504b8c4.

Putting back the bits I moved aside to get a clean rebase.
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!
Merge pull request #2590 from paulp/issue/7486

SI-7486 Regressions in implicit search.
SI-7516 Revert "SI-7234 Make named args play nice w. depmet types"

This reverts commit 83c9c764b528a7a1c1d39c480d22c8e3a71d5a58.

The tests are shunted to 'pending'.

Why revert this seemingly innocous commit? 83c9c764 generates a ValDef whose
tpt TypeTree has no original; this contains a reference to the symbol for `d`.
resetAttrs and the retypecheck assigns a new symbol for d and leaves a the
reference to the prior symbol dangling. The real bug is the resetAttrs concept.
Merge pull request #2601 from retronym/ticket/7516

SI-7516 Revert "SI-7234 Make named args play nice w. depmet types"
SI-7517 Fix higher kinded type inference regression

 - Discovered in 2.10.2-RC1
 - Ostensibly regressed in 7e52fb910b, which conceptually reverted
   part of 0cde930b so that (mutable) TypeVars don't use structural equality.
 - But, does *not* fail if 7e52fb910b is cherry-picked directly after 0cde930b,
   suggesting that it shone a light on a behaviour change in some other commit
   in between the two.
 - Indeed, the true regression came in https://github.com/scala/scala/commit/e5da30b843#L5L3176
 - A targeted revert of e5da30b843 is undesirable, as we'd like SI-6846 to stay fixed

What's happening here? In the enclosed test case, higher kinded type
inference explores two possibilities:

    Composed.this.Split[A]
    K[[T]A[B[T]]]           // `Split[A]` dealiased

The difference in the flow of type inference can be seen from the diff
below. Notice how now we no longer register `?K.addBound(Composed.this.Split)`,
we instead only register `?K.addBound(K)`

```patch
--- sandbox/old.log 2013-05-30 00:27:34.000000000 +0200
+++ sandbox/new.log 2013-05-30 00:28:28.000000000 +0200
@@ -1,55 +1,114 @@
 ?K.unifyFull(Composed.this.Split[A])
   ?K.unifySpecific(Composed.this.Split[A])
-  ?K.addBound(Composed.this.Split)
     ?B.unifyFull(T)
       ?B.unifySpecific(T)
       `-> false
     ?B.unifyFull(Any)
       ?B.unifySpecific(Any)
       `-> false
   `-> false
   ?K.unifySpecific(L[[T]A[B[T]]])
-  ?K.addBound(L)
     ?B.unifyFull(B[T])
       ?B.unifySpecific(B[T])
       ?B.addBound(B)
       `-> true
     ?B.unifyFull(B[T])
       ?B.unifySpecific(B[T])
       ?B.addBound(B)
       `-> true
     ?B.unifyFull(B[T])
       ?B.unifySpecific(B[T])
       ?B.addBound(B)
       `-> true
     ?B.unifyFull(B[T])
       ?B.unifySpecific(B[T])
       ?B.addBound(B)
       `-> true
+  ?K.addBound(L)
   `-> true
 ?K.unifyFull(Composed.this.Split[A])
   ?K.unifySpecific(Composed.this.Split[A])
-  ?K.addBound(Composed.this.Split)
     ?B.unifyFull(x)
       ?B.unifySpecific(x)
       `-> false
   `-> false
   ?K.unifySpecific(L[[T]A[B[T]]])
+    ?B.unifyFull(B[T])
+      ?B.unifySpecific(B[T])
+      ?B.addBound(B)
+      `-> true
+    ?B.unifyFull(B[T])
+      ?B.unifySpecific(B[T])
+      ?B.addBound(B)
+      `-> true
+    ?B.unifyFull(B[T])
+      ?B.unifySpecific(B[T])
+      ?B.addBound(B)
+      `-> true
+    ?B.unifyFull(B[T])
+      ?B.unifySpecific(B[T])
+      ?B.addBound(B)
+      `-> true
   ?K.addBound(L)
+  `-> true
+?K.unifyFull(Composed.this.Split[A])
+  ?K.unifySpecific(Composed.this.Split[A])
+    ?B.unifyFull(T)
+      ?B.unifySpecific(T)
+      `-> false
+    ?B.unifyFull(Any)
+      ?B.unifySpecific(Any)
+      `-> false
+  `-> false
+  ?K.unifySpecific(L[[T]A[B[T]]])
     ?B.unifyFull(B[T])
       ?B.unifySpecific(B[T])
       ?B.addBound(B)
       `-> true
     ?B.unifyFull(B[T])
       ?B.unifySpecific(B[T])
       ?B.addBound(B)
       `-> true
     ?B.unifyFull(B[T])
       ?B.unifySpecific(B[T])
       ?B.addBound(B)
       `-> true
     ?B.unifyFull(B[T])
       ?B.unifySpecific(B[T])
       ?B.addBound(B)
       `-> true
+  ?K.addBound(L)
+  `-> true
+?K.unifyFull(Composed.this.Split[A])
+  ?K.unifySpecific(Composed.this.Split[A])
+    ?B.unifyFull(x)
+      ?B.unifySpecific(x)
+      `-> false
+  `-> false
+  ?K.unifySpecific(L[[T]A[B[T]]])
+    ?B.unifyFull(B[T])
+      ?B.unifySpecific(B[T])
+      ?B.addBound(B)
+      `-> true
+    ?B.unifyFull(B[T])
+      ?B.unifySpecific(B[T])
+      ?B.addBound(B)
+      `-> true
+    ?B.unifyFull(B[T])
+      ?B.unifySpecific(B[T])
+      ?B.addBound(B)
+      `-> true
+    ?B.unifyFull(B[T])
+      ?B.unifySpecific(B[T])
+      ?B.addBound(B)
+      `-> true
+  ?K.addBound(L)
+  `-> true
+?K.unifyFull(L[A])
+  ?K.unifySpecific(L[A])
+  ?K.addBound(L)
+  `-> true
+?K.unifyFull(L[A])
+  ?K.unifySpecific(L[A])
+  ?K.addBound(L)
   `-> true
```