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
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.
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-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.
Convenience method findSymbol.
Add -Xdev to the runtime-visible settings.
Mappings between classes and pickler tags.

This enables a measure of "command/query separation", which is
to say: the same method shouldn't go on a side effecting binge
and also return a value.
Tree traversal: more uniform and granular.

There's a huge amount of tree traversal related duplication
which is hard to eliminate only because trees aren't properly
traversed. The not-quite-tree bits of key trees are ignored
during traversals, making it impossible to write e.g. a
pretty printer without duplicating almost the entire traversal
logic (as indeed is done for printing purposes in more than one
place.) And almost the entire pickler logic is redundant with
Traverser, except since it's all duplicated of course it diverged.
The pickler issue is remedied in the commit to follow.

The not-quite-trees not quite being traversed were Modifiers, Name,
ImportSelector, and Constant. Now every case field of every tree is
traversed, with classes which aren't trees traversed via the following
methods, default implementations as shown:

  def traverseName(name: Name): Unit                    = ()
  def traverseConstant(c: Constant): Unit               = ()
  def traverseImportSelector(sel: ImportSelector): Unit = ()
  def traverseModifiers(mods: Modifiers): Unit          = traverseAnnotations(mods.annotations)
Eliminate redundant pickling code.

This commit drops about 700 lines of redundant traversal logic.

There had been ad hoc adjustments to the pickling scheme here and
there, probably in pursuit of tiny performance improvements.
For instance, a Block was pickled expr/stats instead of stats/expr,
a TypeDef was pickled rhs/tparams instead of tparams/rhs.
The benefits derived are invisible compared to the cost of having
several hundred lines of tree traversal code duplicated in half a
dozen or more places.

After making Traverser consistent/complete, it was a straightforward
matter to use it for pickling. It is ALSO now possible to write a
vastly cleaner tree printer than the ones presently in trunk, but I
leave this as an exercise for Dear Reviewer.
Merge remote-tracking branch 'scala/master' into fix-merge-3018

Conflicts:
	src/compiler/scala/tools/nsc/typechecker/Typers.scala