SI-8134 SI-5954 Fix companions in package object under separate comp.

The tests cases enclosed exhibited two failures modes under
separate compilation.

  1. When a synthetic companion object for a case- or implicit-class
     defined in a package object is called for,
     `Namer#ensureCompanionObject` is used to check for an explicitly
     defined companion before decided to create a synthetic one.
     This lookup of an existing companion symbol by `companionObjectOf`
     would locate a symbol backed by a class file which was in the
     scope of the enclosing package class. Furthermore, because the
     owner of that symbol is the package object class that has now
     been noted as corresponding to a source file in the current
     run, the class-file backed module symbol is *also* deemed to
     be from the current run. (This logic is in `Run#compiles`.)

     Thinking the companion module already existed, no synthetic
     module was created, which would lead to a crash in extension
     methods, which needs to add methods to it.

  2. In cases when the code explicitly contains the companion pair,
     we still ran into problems in the backend whereby the class-file
     based and source-file based symbols for the module ended up in
     the same scope (of the package class). This tripped an assertion
     in `Symbol#companionModule`.

We get into these problems because of the eager manner in which
class-file based package object are opened in `openPackageModule`.
The members of the module are copied into the scope of the enclosing
package:

    scala> ScalaPackage.info.member(nme.List)
    res0: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462

    scala> ScalaPackage.info.member(nme.PACKAGE).info.member(nme.List)
    res1: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462

This seems to require a two-pronged defense:

  1. When we attach a pre-existing symbol for a package object symbol
     to the tree of its new source, unlink the "forwarder" symbols
     (its decls from the enclosing
     package class.

  2. In `Flatten`, in the spirit of `replaceSymbolInCurrentScope`,
     remove static member modules from the scope of the enclosing
     package object (aka `exitingFlatten(nestedModule.owner)`).

This commit also removes the warnings about defining companions
in package objects and converts those neg tests to pos (with
-Xfatal-warnings to prove they are warning free.)

Defining nested classes/objects in package objects still has
a drawback: you can't shift a class from the package to the
package object, or vice versa, in a binary compatible manner,
because of the `package$` prefix on the flattened name of
nested classes. For this reason, the `-Xlint` warning about
this remains. This issue is tracked as SI-4344.

However, if one heeds this warning and incrementatlly recompiles,
we no longer need to run into a DoubleDefinition error (which
was dressed up with a more specific diagnostic in SI-5760.)
The neg test case for that bug has been converted to a pos.
SI-5954 Invalidate TypeRef cache when opening package object

I noticed that the pos/5954d was tripping a println "assertion".
This stemmed from an inconsistency between
`TypeRef#{parents, baseTypeSeq}` for a package objects compiled
from source that also has a class file from a previous compilation
run.

I've elevated the println to a devWarning, and changed
`updatePosFlags`, the home of this evil symbol overwriting,
to invalidate the caches in the symbols info. Yuck.

I believe that this symptom is peculiar to package objects because
of the way that the completer for packages calls `parents` during
the Namer phase for package objects, before we switch the symbol
to represent the package-object-from-source. But it seems prudent
to defensively invalidate the caches for any symbol that finds its
way into `updatePosFlags`.
SI-5954 Add a TODO comment with an idea for future work

As the prophet once said:

  "'Tis better to never do at all than to have do and undo"

Let's try that in 2.12.
SI-8134 Address pull request feedback

Aesthetics only.
SI-7753 InstantiateDependentMap narrows type of unstable args

[Most of this comment and the initial fix were implemented by Jason Zaugg.
I just cleaned it up a bit.]

After a soundness fix in SI-3873, instantiation of dependent
method type results behaved differently depending on whether the argument
from which we were propagating information had a stable type
or not. This is particular to substitution into singleton types
over the parameter in question.

If the argument was stable, it was substituted into singleton
types, such as the one below in the prefix in `a.type#B`
(which is the longhand version of `a.B`)

  scala> class A { type B >: Null <: AnyRef }
  defined class A

  scala> object AA extends A { type B = String }
  defined object AA

  scala> def foo(a: A): a.B = null
  foo: (a: A)a.B

  scala> foo(AA)
  res0: AA.B = null

But what if it isn't stable?

  scala> foo({def a = AA; a: A { type B <: String}})
  res1: a.B = null

This commit changes that to:

  scala> foo({def a = AA; a: A { type B <: String}})
  res1: A{type B <: String}#B = null
SI-8244 Fix raw type regression under separate compilation

In #1901, handling of raw types encountered in signatures during class
file parsing was changed to work in the same manner as
`classExistentialType`, by using
`existentialAbstraction(cls.tparms, cls.tpe_*)`

But this never creates fresh existential symbols, and just sticks
the class type parameters it `quantified`:

	scala> trait T[A <: String]
	defined trait T

	scala> val cls = typeOf[T[_]].typeSymbol
	cls = trait T#101864

	scala> cls.typeParams
	res0 = List(type A#101865)

	scala> cls.tpe_*
	res1 = T#101864[A#101865]

	scala> classExistentialType(cls)
	res3 = T#101864[_ <: String#7209]

	scala> val ExistentialType(quantified, result) = res3
	List(type A#101865)

In the enclosed test case, this class type parameter was substituted
during `typeOf[X] memberType sym`, which led us unsoundly thinking
that `Raw[_]` was `Raw[X]`.

I've added a TODO comment to review the other usages of
`classExistentialType`.

Test variations include joint and separate compilation, and the
corresponding Scala-only code. All fail with type errors now,
as we expect. I've also added a distillation of a bootstrap
error that failed when I forgot to wrap the `existentialType`.
Merge pull request #3518 from adriaanm/t7753

SI-7753 InstantiateDependentMap narrows type of unstable args
Merge pull request #3519 from adriaanm/rebase-3483

SI-8244 Fix raw type regression under separate compilation
SI-5900 Pending test to show that SI-7886 persists

    qbin/scalac test/pending/neg/t7886b.scala && qbin/scala Test
    java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
        at Test$$anon$1.accept(t7886b.scala:15)
        at Test$.g(t7886b.scala:9)
SI-5900 Fix pattern inference regression

This commit does not close SI-5900. It only addresses a regression
in 2.11 prereleases caused by SI-7886.

The fix for SI-7886 was incomplete (as shown by the last commit)
and incorrect (as shown by the regression in pos/t5900a.scala and
the fact it ended up inferring type parameters.)

I believe that the key to fixing this problem will be unifying
the inference of case class constructor patterns and extractor
patterns.

I've explored that idea:

  https://gist.github.com/retronym/7704153
  https://github.com/retronym/scala/compare/ticket/5900

But didn't quite get there.
Merge pull request #3523 from adriaanm/rebase-3514

 Fix pattern inference regression
Merge pull request #3389 from retronym/ticket/8134-2

SI-8134 SI-5954 Fix companions in package object under separate comp.