SI-7801 Fix a nightmarish bug in Symbols#adaptInfos

The compiler-in-residence has always been a sketchy affair;
FSC and REPL offers a bounty of bugs that exploit the menagerie
of time-travel mechanisms in play for symbols' metadata (type, flags,
name and owner.) but are often cleverly masked by optimizations in
the compiler based on reference equality.

The latest: an innocuous change in Erasure:

  https://github.com/scala/scala/commit/d8b96bb8#commitcomment-3995163

means that some `ErasureMap`-s over `MethodType`-s are now true
identities (as `UnitTpe` is always the same object, whereas
`erasedTypeRef(UnitClass)` returns an different `TypeRef` each
time.)

This, in turn, enables `TypeMap#mapOver` to reuse
the existing enclosing type, and so on. On such subtleties hinge
further optimizations, such as whether or not a given phase's
`InfoTransformer` needs to add an entry in a symbols type history.

When the REPL (or FSC / Presentation Compiler) creates a new
`Run`, `Symbol#rawInfo` tries to adapt the entries in the type
history for the new run. For packages, this was taken to be a
no-op; each entry is marked as being valid in the new run and
no further action is taken. This logic lurks in `adaptInfos`.

But, when the namer enters a new symbol in a package, it
*mutates* the Scope of that package classes info `enteringTyper`.
So the later entries in the type history *must* be invalidated
and recomputed.

We have two choices for a fix:

 1) modify `Namers#enterInScope` to blow away the subsequent
    type history for the owning symbol after inserting the
    new member. Something like `owner.setInfo(owner.info)` would
    have the desired effect.
 2) Change `adaptInfos` to be more conservative when it comes
    to package classes, and retain only the oldest entry in the
    type history.

This commit goes for option #2.