Fix SI-4560, NoSuchMethodErrors involving self types.

Following this commit are reversions of three prior commits which
introduced difficulties of their own, plus extra tests for this
issue and SI-4601, all of which I pinched from jrudolph.

Maybe there was a good reason for some of the complicated code
related to this ticket. I took the naive position that if we avoided
generating a method call to a particular receiver if the receiver
has no such method, we would encounter fewer NoSuchMethodErrors.

I would believe one can construct a scenario which this doesn't
handle correctly, but it's hard to believe this isn't a big
improvement. Review by @jrudolph, @odersky.
Revert fix part of "Closes 4560. Review by dragos."

This reverts commit 7127d8293775905acd0d04e21d9e045b5c029261.

Conflicts:

	test/files/run/t4560.scala
Revert "Closes #4560. Review by dragos." (introduction of safeREF)

This reverts commit 124cf3f9cbdc582a432c13edd229ba9b8726b99f.

Conflicts:

	src/compiler/scala/tools/nsc/transform/CleanUp.scala
Revert "tentative fix for RC5 lift build problem."

This reverts commit cb4fd65825f3c88908103e48d0d7e89d70d26c22.

Conflicts:

	src/compiler/scala/tools/nsc/symtab/Types.scala
	src/compiler/scala/tools/nsc/typechecker/Contexts.scala
SI-4560 - improved test

Added all the known cases of failing self-types. Added tests for symbol
access (SI-4601) as well which should now be fixed for all of the same cases
as well.
Remove typesafe-config as dependency for library.  Akka-actors will draw it in.
SI-5958 This deserves a stable type

`this` (or the self variable) passed as an actual argument to a method
should receive a singleton type when computing the method's resultType

this is necessary if the method's type depends on that argument
Merge pull request #993 from jsuereth/fix/typesafe-config-removal

Remove typesafe-config as dependency for library.  Akka-actors will draw...
SI-6142: warn @inline-methods ending up not inlined (rightfully or not)
Improve unchecked warnings a lot.

Don't warn on "uncheckable" type patterns if they can be
statically guaranteed, regardless of their runtime checkability.
This covers patterns like Seq[Any] and lots more.

Review by @adriaanm.
Cleared the remaining unchecked warnings in trunk.
Eliminated remainder of "catches Throwable" warnings.

And also non-exhaustive matches.

And added -nowarn to the build options for scalacheck,
we don't need to hear the warnings for code we aren't
able to fix.
Changed isHidden condition back to isSynthetic.

Since we were blessed with spurious warnings.

With this commit I have eliminated every warning in trunk
except for deprecation, feature, and inliner warnings, plus
one due to SI-6146.  I'm not going to count "pattern matcher
performance warnings" which are presently preventing me from
turning on -unchecked even though there are no genuine
-unchecked warnings remaining.  Hey, get your own option!

Conflicts:
	src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
Eliminated all the current feature warnings.

This pretty much takes us down to deprecation and inliner warnings.
Fix a few scaladoc tests I broke.
Merge pull request #1004 from paulp/topic/warnings-2.10.x

Topic/warnings 2.10.x
Closed 6029 ...

... in a less nice way than I would like. Essentially, we mask type errors at later stages that arise from comparing existentials and skolems because we know that they are not tracked correctly through all tree transformations. Never mind that all these types are going erased anyway shortly afterwards. It does not smell nice. But as I write in the comment, maybe the best way out is to
avoid skolems altogether. Such a change by far exceeds the scope of this pull request however.
Merge pull request #1010 from odersky/ticket/6029

Closed SI-6029 ...
Merge pull request #991 from adriaanm/ticket-5958

SI-5958 This deserves a stable type
Merge pull request #1002 from magarciaEPFL/fixes210

SI-6142: warn @inline-methods ending up not inlined (rightfully or not)