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
Describe type parameter interpolation in @implicitNotFound documentation

Using this feature is necessary for helpful error messages, so it should be documented.

Thank you to @adriaanm for recommending the this description.
no longer warns on calls to vampire macros

As eloquently elaborated and cleverly named by Travis Brown, macros
defined in structural types are useful:
http://meta.plasm.us/posts/2013/07/12/vampire-methods-for-structural-types/.

However, since such macros are on the intersection of a number of language
features, as usual, there are bugs.

This commit fixes an unwanted interaction of macros defined in structural
types with the scala.language.reflectiveCalls guard. Since macro calls
aren't going to be carried to runtime, there's no need to warn about them.
Simplify partest.task target, fix typo in comment.
Clarify findMembers, add reverse engineered docs

When looking for deferred members, it only makes sense
to retry when deferred members aren't excluded.
Single Abstract Method support: synthesis helpers

`synthesizeSAMFunction` will be used to expand the following tree:

```
{ (p1: T1, ..., pN: TN) => body } : S
```

to:

```
{
 def apply$body(p1: T1, ..., pN: TN): T = body

 new S { def apply(p1: T1, ..., pN: TN): T = apply$body(p1,..., pN) }
}
```

The expansion assumes `S` (the expected type) defines a single abstract method
(let's call that method `apply` for simplicity).

1. If 'T' is not fully defined, it is inferred by type checking
`def apply$body` without a result type before type checking the block.
The method's inferred result type is used instead of T`.
[See test/files/pos/sammy_poly.scala]

2. To more easily enforce S's members are not in scope in `body`, that tree
goes to the `apply$body` method that's outside the anonymous subclass of S.
(The separate `apply$body` method simplifies the implementation of 1&2.)

3. The following restrictions apply to S:
  1. Its primary constructor (if any) must be public, no-args, not overloaded.
  2. S must have exactly one abstract member, its SAM
  3. SAM must take exactly one argument list
  4. SAM must be monomorphic

We may later relax these requirements to allow an implicit argument list,
both on the constructor and the SAM. Could also let the SAM be polymorphic.
Single Abstract Method support: synthesize SAMs

Under `-Xexperimental`, `typedFunction` invokes `synthesizeSAMFunction`
when the expected type for the function literal (`pt`) is not the built-in
`FunctionN` type of the expected arity, but `pt` does have a SAM
with the expected number of arguments.

PS: We'll require `import language.sam` instead of `-Xexperimental`,
as soon as the SIP is ready and there are more tests.
Generalize OverridingPairs to SymbolPairs.

Increases your chance of knowing what is going on in
OverridingPairs. Introduces some new abstractions which I
hope for your own sakes you will put to use in some way:

  RelativeTo: operations relative to a prefix
  SymbolPair: two symbols being compared for something, and
    the enclosing class where the comparison is being performed

Fixed a minor bug with access by accident by way of more
principled pair analysis. See run/private-override.scala.

Upgraded the error message issued on certain conflicts
to give the line numbers of both conflicting methods, as
opposed to just one and you go hunting.
Extract isStable and isVolatile from Type.

As with finalResultType, this is easier to control
and WAY easier to understand. Look, all the relevant
code fits on half a screenful rather than being
spread out over 5000 lines and you have to be
constantly conscious of what is overriding what.

Truly it would be hard to damn the indiscriminate
use of subtype polymorphism any more soundly than
does this, by way of contrast:

  def isStable(tp: Type): Boolean = tp match {
    case _: SingletonType                             => true
    case NoPrefix                                     => true
    case TypeRef(_, NothingClass | SingletonClass, _) => true
    case TypeRef(_, sym, _) if sym.isAbstractType     => tp.bounds.hi.typeSymbol isSubClass SingletonClass
    case TypeRef(pre, sym, _) if sym.isModuleClass    => isStable(pre)
    case TypeRef(_, _, _) if tp ne tp.dealias         => isStable(tp.dealias)
    case TypeVar(origin, _)                           => isStable(origin)
    case AnnotatedType(_, atp, _)                     => isStable(atp)    // Really?
    case _: SimpleTypeProxy                           => isStable(tp.underlying)
    case _                                            => false
  }

That's all of it! If there are bugs in it (of course there are)
some might even be found now.
SI-7899 Don't infer by-name types during, e.g. eta-expansion

Given:

    def id[A](a: A): A = a
    def foo(f: (=> Int) => Int) = ()
    foo(id)

We eta-expanded `id` and inferred `A` to be `=> Int` to satisfy the
expected type set forth by the formal parameter `f`.

We really shouldn't go about inferring types that we can't *write*.
Our attempt to do so led promptly into a `ClassCastException` in the
enclosed test.

This commit:

  - drops by-name-ness during `inferExprInstance`
  - tests that this results in a type error for the reported bug
    (neg/t7899)
  - tests that a method with a by-name parameter can still be
    eta expanded to match function with a corresponding by-name
    parameter (run/t7899)
  - discovers the same latent CCE in pos/t7584
     - now that would be a type error
     - so we compensate by using placeholder functions rather than
       eta-expansion.
     - and move that that test to `run` for good measure.
Merge pull request #3014 from ceedubs/pr/implicitNotFound-scaladoc

Describe type parameter interpolation in @implicitNotFound documentation
Don't pursue SAM translation after an arity mismatch.

Before this change:

    scala> trait T { def apply(a: Int): Int }
    defined trait T

    scala> ((x: Int, y: Int) => 0): T
    <console>:9: error: object creation impossible, since method apply in trait T of type (a: Int)Int is not defined
                  ((x: Int, y: Int) => 0): T
                                    ^
After the change, these cases report the same errors as they do
*without* -Xexperimental.
Extract SerialVersionUIDAnnotation. Make SAM body synthetic.

Addressing review feedback.
Single Abstract Method support: java8 test

Inspired by test/files/run/t7398.scala and sammy_poly.
Added some notes to original tests.

Elaborating on that note: we don't yet desugar `f(a)` to `f.sam(a)`,
like we do for regular functions: `f(a)` becomes `f.apply(a)`.

It seems pleasingly symmetrical and is easy to implement,
but not sure it's a good idea...
Remove stray debug comment
SI-7895 Avoid cascade of "symbol not found" in pattern matches

If we can't type check the `Foo` in `case Foo(a, b) => (a, b)`,
we should enter error symbols for `a` and `b` to avoid further
errors being reported in the case body.
SI-7895 Issue all buffered errors after silent mode.

Rather than just the first.

For example, `foo(wizzle, wuzzle, woggle)` should report all three
not-found symbols.