SI-7783 Don't issue deprecation warnings for inferred TypeTrees

Deprecation checks in RefChecks were looking into all TypeTrees
to find references to deprecated type aliases. However, when the
compiler infers a type argument or type of a member it creates
a TypeTree (with a null original) that was also leading to warnings.

I ran into this problem often when upgrading a build from SBT 0.12
to 0.13: a plugin I was using used the deprecated type alias, and I
suffered transitively when I used methods from its API.

This commit disables the checks for inferred TypeTree-s.
Bump version to 2.10.4 for nightlies
Merge pull request #3009 from adriaanm/2.10.4

Bump version to 2.10.4 for nightlies
Merge pull request #2985 from retronym/ticket/7783

 Don't issue deprecation warnings for inferred TypeTrees
SI-3346 implicit parameters can now guide implicit view inference

This simple patch makes it possible for implicit views to benefit from
fundep-guided type inference, eliminating a nasty special case in
implicit inference.

Here are the changes that I had to apply to the tests (they exposed
quite a number of interesting questions that I was happy to answer):

1) neg/t5845.scala now works, so I moved it to pos. That easily makes sense,
because the test was just a canary to track previous state of things.

2) neg/divergent_implicit.scala, neg/t5578.scala and neg/t7519.scala
changed their messages to less informative ones, because inapplicable
implicit views now get disqualified early and therefore don't display
their error messages to the user. This is an unfortunate but necessary
byproduct of this change, and one can argue that the behavior is now
completely consistent with implicit vals (that also don't explain why
this or that implicit val got disqualified, but rather display a generic
implicit value not found message).

3) scaladoc/implicits-chaining.scala and scaladoc/implicits-base.scala.
Immediate culling of apriori inapplicable implicit views messes things up
for Scaladoc, because it's interested in potentially applicable views,
having infrastructure to track various constraints (type bounds, requirements
for implicit parameters, etc) that guide applicability of views and then
present it to the user. Therefore, when scaladoc is detected, implicit search
reverts to the old behavior.

4) We still cannot have Jason's workaround to type constructor inference
mentioned in comments to SI-3346, because it's not really about implicit
parameters of implicit views, but about type inference flowing from the
implicit parameter list to a preceding parameter list in order to affect
inference of an implicit view. This is something that's still too ambitious.
Merge remote-tracking branch 'scala/2.10.x' into merge-2.10.x

Conflicts:
	build.number
	test/files/neg/classmanifests_new_deprecations.check
SI-7688 Fix AsSeenFrom of ThisType from TypeVar prefix

Restores behaviour for the AsSeenFrom before the refactoring
in b457b6c477.

This commit uniformly considered that a `TypeVar` prefix should not
`matchesPrefixAndClass`; a condition that formerly was only applied
if the type being viewed was a `TypeRef`. This condition was
originally added in cc9e8eda3364d as a backstop for pos/t2797.scala.

This commit leaves that backstop in place where it was, although it
expresses it more directly by checking if `pre baseType clazz` is
`NoType`, which was the case that cropped up in SI-2797:

    scala> type T = bc._1.type forSome { val bc: (AnyRef, AnyRef) }
    warning: there were 1 feature warning(s); re-run with -feature for details
    defined type alias T

    scala> val et = typeOf[T].dealias.asInstanceOf[ExistentialType]
    et: $r.intp.global.ExistentialType = bc._1.type forSome { val bc: (AnyRef, AnyRef) }

    scala> et.withTypeVars( { x =>
         |   println(x.prefix.typeSymbol)
         |   println(x.prefix.typeSymbol.isSubClass(typeOf[Tuple2[_, _]].typeSymbol))
         |   println(x.prefix.baseType(typeOf[Tuple2[_, _]].typeSymbol))
         |   true
         | } , reflect.internal.Depth(0))
    type bc.type
    true
    <notype>
    res98: Boolean = true
Test cases for SAM restrictions.

Only one seems to indicate something new:

  ((x: Int) => 0): NonClassType

I believe that we shouldn't pursue SAM translation for that case,
and fallthrough to Function1. That would allow for an implicit view
to finish the job.
Merge pull request #3045 from retronym/ticket/7688-4

 Fix AsSeenFrom of ThisType from TypeVar prefix
Merge pull request #3048 from adriaanm/sammy_tests

Test cases for SAM restrictions.
Merge pull request #3041 from gkossakowski/merge-2.10.x

Merge 2.10.x into master
Merge pull request #3030 from xeno-by/topic/fundep-views

SI-3346 implicit parameters can now guide implicit view inference