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`.

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

But, when 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.