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/5954 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.