update docs for (partial) fun synth in uncurry
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
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.
SI-6089 test file for pt2

test that matchEnd that's an argument of || that's in tail position is in tail position
Merge pull request #972 from adriaanm/ticket-6089

SI-6089 test file for pt2
Merge pull request #965 from dragos/fix-package-prefix

Handle multiple packages in one source file in the presentation compiler.
Improve unchecked warnings.

Spurious test was not good.  Better test avoids suppressing
some legitimate warnings.  Review by @moors.
Merge pull request #964 from odersky/ticket/6090

SI-6090 correct rewriting of overloaded value class ==
SI-4881 infer variance from formals, then result

Changed behavior so that when determining the target variance of a method parameter,
the variance in formals comes first. If variance is still undecided by that,
the variance in the result type is used as a secondary criterion.

(This is also done when determining prototype type params.)