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 { … }
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.
Removed "core classes first" logic.

I see no evidence this is necessary, and it should be wildly
uncontroversial that if we can lose this, we should. Hardcoded filenames
which don't even exist in the repository ("StandardEmbeddings.scala",
"EmbeddedControls.scala") have no place in compiler source. If some
portion of this is believed necessary then better evidence of that
should be offered.

Review by @lrytz.
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.)
SI-4440 workaround: avoid outer accessor that'll vanish

outer accessors of final classes are dropped in constructors
apply some foresight in explicit outer and replace those doomed outer checks by `true`
(since this is unfortunate, we generate an unchecked warning)
[doc] Fix example of `Ordering.on` usage.
Small changes to reflection API to make it safe for IDE use.

* Removed `typeSymbol` and `termSymbol` from `reflect.api.base`, and pushed them down to
  `reflect.api`.
* extracted `TypeTree.symbol` to a top-level method so it can be overridden in other layers
SI-6111 accept single-subpattern unapply pattern

An extractor pattern `X(p)` should type check for any `X.unapply`/`X.unapplySeq`
that returns an `Option[_]` -- previously we were confused about the case where
it was an `Option[(T1, ... , Tn)]`. In this case, the expected type for the
pattern `p` is simply `(T1, ... , Tn)`.

While I was at it, tried to clean up unapplyTypeList and friends (by replacing them by extractorFormalTypes).

From the spec:
   8.1.8 ExtractorPatterns

   An extractor pattern x(p1, ..., pn) where n ≥ 0 is of the same syntactic form as a constructor pattern.
   However, instead of a case class, the stable identifier x denotes an object which has a member method named unapply or unapplySeq that matches the pattern.
   An unapply method in an object x matches the pattern x(p1, ..., pn) if it takes exactly one argument and one of the following applies:

   n = 0 and unapply’s result type is Boolean.

   n = 1 and unapply’s result type is Option[T], for some type T.
     the (only) argument pattern p1 is typed in turn with expected type T

   n > 1 and unapply’s result type is Option[(T1, ..., Tn)], for some types T1, ..., Tn.
     the argument patterns p1, ..., pn are typed in turn with expected types T1, ..., Tn
Merge pull request #975 from adriaanm/ticket-4881b

SI-4881 infer variance from formals, then result
docs related to fix for SI-6111
Merge pull request #979 from adriaanm/ticket-6111

SI-6111 accept single-subpattern unapply pattern
Merge pull request #974 from adriaanm/repull-unchecked-hk

Improve unchecked warnings.