correctly fails implicit search for invalid implicit macros

There was a rare corner case when implicit search wouldn’t discard
an invalid implicit macro (e.g. the one with mismatching macro impl or
the one with macro impl defined in the same compilation run) during
typechecking the corresponding candidate in typedImplicit1. This is now fixed.
SI-7983 Fix regression in implicit divergence checking

As seen in Slick. Regressed in 039b1cb1a5b8.

In that commit, a call to `normalize` was replaced with `dealiasWiden`
as part of a broad sweeping change. However, while the latter does
less than the former with regards to eta expansion ofhigher kinded
type refs (the motivation of that commit), it also does more when it
comes to singleton types: they are widened to the underlying type.

This was widening away `SingleType(<<package a.b>>, <<package c>>)`
before the special case assiging that type component a complexity of
zero could kick in.

In the test case, extracted from Slick, this meant that the
divergence check would consider that the second type below to
outrank the first in the complexity measure, and abort the implicit
search.

    Shape[?,                        ?  (Coffees, Coffees), ?]
    Shape[DivergenceTest.this.Flat, ?, Coffees,            ?]

After this change, the number of packages enclosing `DivergenceTest`
no longer has a bearing on the complexity score of the type.

Here's how the race was run before hand:

	complexity(<noprefix>): 0
	complexity(<root>): 1
	complexity(foo.type): 2
	complexity(foo.bar.type): 3
	complexity(foo.bar.baz.type): 4
	complexity(DivergenceTest.this.type): 5
	complexity(<noprefix>): 0
	complexity(<root>): 1
	complexity(foo.type): 2
	complexity(foo.bar.type): 3
	complexity(foo.bar.baz.type): 4
	complexity(DivergenceTest.this.type): 5
	complexity(DivergenceTest.this.Flat): 6
	complexity(<noprefix>): 0
	complexity(<root>): 1
	complexity(scala.type): 2
	complexity(Int): 3
	complexity(?): 1
	complexity(DivergenceTest.this.Shape2[DivergenceTest.this.Flat,Int,?]): 16

	complexity(<noprefix>): 0
	complexity(<root>): 1
	complexity(foo.type): 2
	complexity(foo.bar.type): 3
	complexity(foo.bar.baz.type): 4
	complexity(DivergenceTest.this.type): 5
	complexity(?): 1
	complexity(<noprefix>): 0
	complexity(<root>): 1
	complexity(scala.type): 2
	complexity(<noprefix>): 0
	complexity(Coffees): 1
	complexity(<noprefix>): 0
	complexity(<root>): 1
	complexity(scala.type): 2
	complexity(Int): 3
	complexity((Coffees, Int)): 7
	complexity(?): 1
	complexity(DivergenceTest.this.Shape2[?,(Coffees, Int),?]): 15

	dominates(DivergenceTest.this.Shape2[_ <: DivergenceTest.this.Flat, Int, U2], DivergenceTest.this.Shape2[_ <: Level, (Coffees, Int), U1]): true

And afterwards:

	complexity(DivergenceTest.this.type): 1
	complexity(DivergenceTest.this.type): 1
	complexity(DivergenceTest.this.Flat): 2
	complexity(scala.type): 1
	complexity(Int): 2
	complexity(?): 1
	complexity(DivergenceTest.this.Shape2[DivergenceTest.this.Flat,Int,?]): 7

	complexity(DivergenceTest.this.type): 1
	complexity(?): 1
	complexity(scala.type): 1
	complexity(<noprefix>): 0
	complexity(Coffees): 1
	complexity(scala.type): 1
	complexity(Int): 2
	complexity((Coffees, Int)): 5
	complexity(?): 1
	complexity(DivergenceTest.this.Shape2[?,(Coffees, Int),?]): 9

	dominates(DivergenceTest.this.Shape2[_ <: DivergenceTest.this.Flat, Int, U2], DivergenceTest.this.Shape2[_ <: Level, (Coffees, Int), U1]): false

Notice that even in the after shot, `scala.Int` has a complexity of 2.
It should be 1; this will be fixed in a separate commit.
Code reformatting in Implicits

And use List#sum, rather than a fold.

No functional change.
Account for a variation of package types in Implicit Divergence.

While debugging pos/t7983.scala, I noticed that:

    complexity(scala.type): 1
  complexity(Int): 2

The intent of the code is that top level classes should have
a complexity of one. This commit restores that for cases when
we see the prefix type as a ThisType, rather than a SingleType.

I can't construct a test case in which this small difference
is observable in the divergence checks.
SI-7999 s.u.c.NonFatal: StackOverflowError is fatal

As demonstrated in
https://groups.google.com/d/topic/scala-language/eC9dqTTBYHg, SOEs
should be considered fatal, because all popular JVM implementations
seem to run into inconsistent state (ignoring finally blocks leading
to not running monitorExit, leading to locks not being unlocked, ...)
if one just pushes them enough.
Merge pull request #3160 from retronym/ticket/7983

Fix implicit divergence regression
Merge pull request #3182 from soc/SI-7999

 s.u.c.NonFatal: StackOverflowError is fatal
Update Eclipse classpath files
Merge pull request #3137 from xeno-by/topic/implicit-macros-invalidate-on-error

correctly fails implicit search for invalid implicit macros
Revise paragraph (a revised #3164)

Revise text further, following suggestions in #3164 and part of the suggestions by @som-snytt. But I've kept "appear", since this paragraph documents the external behavior, not the implementation.
Merge pull request #3186 from Blaisorblade/patch-1

Revise paragraph (a revised #3164)
Merge pull request #3185 from sschaef/update-eclipse-classpath

Update Eclipse classpath files