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

My first attempts to fix this bug involved elaborate contortions
to change `Run#compiles` to better detect which symbols come from
source; and in addition I modified `Flatten` to add code similar to
`replaceSymbolInCurrentScope` to treat static modules.

But there turned out to be a much more direct means of attack:
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.

Voila.

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.
Simplify flatten transformer with a map with default

No need to initialize the buffers of lifted definitions as
we traverse to the owners; we can just install a default
in the map instead.