Fix for SI-5385.

Nodes which hit EOF with no whitespace afterward had
wrong position.
update docs for (partial) fun synth in uncurry
Removes redundant outers

Widens the criterion when outer fields can be omitted. It used to be that sub- and superclass had to be enclosed by the same outer class. Only in that case was the outer field of the class omitted. We now omit if subclass is contained in an outer class that is itself a subclass of the superclasses outer class.

See test case "outertest.scala" for an example.
SI-1832 consistent symbols in casedef's pattern&body

the only change to typedBind in this commit (beyond refactoring to keep my eyes from bleeding),
is explained by the added comment:

have to imperatively set the symbol for this bind to keep it in sync with the symbols used in the body of a case
when type checking a case we imperatively update the symbols in the body of the case
those symbols are bound by the symbols in the Binds in the pattern of the case,
so, if we set the symbols in the case body, but not in the patterns,
then re-type check the casedef (for a second try in typedApply for example -- SI-1832),
we are no longer in sync: the body has symbols set that do not appear in the patterns
since body1 is not necessarily equal to body, we must return a copied tree,
but we must still mutate the original bind
address "this would catch all throwables" warnings

original patch by @odersky in #955 -- criterion for the refactor:
"catch Throwable as long as there's no obvious control flow exception going through the catch
and the caught exception is processed further"

rebased & updated with review comments in #955 and #954
Merge pull request #924 from hubertp/2.10.x-issue/5385

Fix for SI-5385.
Merge pull request #954 from odersky/optimize/outer

Removes redundant outers
Merge pull request #957 from adriaanm/annoying-throwable

address "this would catch all throwables" warnings
Scaladoc: Removing forgotten debugging info

(blush)
Linked the PR policy in the README file.
Merge pull request #962 from dragos/docs/readme-link-to-pr-policy

Add link to the PR policy in the README
SI-6089 pt2: _ is tailpos in `_ || _` and `_ && _`

pull #939 made tail position detection for matches more strict to fix SI-6089,
but became too strict: need to include the tail positions `_` in `_ || _` and `_ && _`.
SI-6090

Sharpens the test so that only Object_== and Object_!= methods on valueclasses may be rewritten in posterasure, whereas user-defined methods are not rewritten.
Handle multiple packages in one source file in the presentation compiler.

The PC symbol loader would mistakenly refuse to enter symbols if more than one package declaration occurred
in the same file. This has become common practice:

     package object foo { … } 
     package foo { … }
Merge pull request #961 from VladUreche/issue/scaladoc

Scaladoc: Removing forgotten debugging info
Merge pull request #963 from adriaanm/ticket-6089

SI-6089 pt2: _ is tailpos in `_ || _` and `_ && _`
Merge pull request #958 from adriaanm/ticket-1832

SI-1832 consistent symbols in casedef's pattern&body
Renaming files to please ant.

"If the names don't fit, do not commit!"
Tweak to symbol tracer.

Stop recording symbols once the shutdown hook is triggered
so that the symbols created in the act of dumping the symbols
do not pollute the view of what symbols were created naturally.
Fix SI-6117, regression involving import ambiguity.

Today I learned that

  foo.member("bar") != foo.member("bar")

if bar is overloaded, because each lookup of an overloaded member
creates a new symbol (with equivalent OverloadedTypes.) How should symbols
be compared so these do not appear unequal? Is there a method which
unpacks the alternatives and compares them individually? It seems likely
there are additional bugs which arise from not covering this case.

Since this bug is in the context of importing, if the prefixes are
identical then I can compare the names instead of the symbols and this
issue goes away. But for the rest of the time during which one might
encounter overloaded symbols, that would be a very lossy operation,
since the overloaded symbol might be encoding any subset of the members
with that name.

There are lots of references to "OverloadedSymbol" in the comments of
various methods in Types, but no such class is visible in the history.
If we had such a thing, we could refine its equals method to recognize
equivalent overloads.

Review by @odersky.