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

I identified two issues that contributed to these bugs.

  1. On separate compilation, package scopes could end up containing
     two symbols representing a package-object nested module, one of
     them based on a `ClassfileLoader`. This led to the failure mode
     of an assertion tripping when looking up a `companionModule` in
     the backend.

  2. `ensureCompanionObject`, which is responsible for creating a
     synthetic companion object for case classes and derived value
     classes when none is declared in source, was getting a wrong
     answer from `Run#compiles` and retaining, rather than discarding,
     the class-file backed symbol from the previous compilation.

This commit:

  - unlinks any same-named symbols of static modules from its
    post-flatten owner (ie, the enclosing package class).
  - tracks all classes and modules within package objects directly in
    `Run#symSource` in order to be able to accurately determine if
    the current run compiles such a symbol.
  - 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.)
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.