Fix a mutation-during-iteration bug in package object loading

[retronym]

The deferredOpen mechanism was added in the 2.13.x series to avoid prematurely loading a package.class prior to finding that the current sources contain the source of this that package object. #9661

This mechanism was refined to support a use case with -Yimports (custom predef imports). (#10333)

The original change to packageObjects appears to have have incorrectly put the "load whatever is is left in deferredOpen logic in apply (per unit logic) rather than run (per-phase logic). I've moved it.

We then need to take a defensive copy of the collection before iteration asn openPackageModule can trigger typechecking of package object template parents, which now mutates deferredOpen. The behaviour is undefined in this case.

I've also switched the backing collection to a j.u.LinkedHashSet which fails fast when if we mutate during iteration. The enclosed test fails before the final commit make it green. I figured that using a Linked collection would make the compilation order deterministic between runs which might help diagnose any remnant bugs in this area.

[lrytz]

Looks good! Compiling src/library also triggers the ConcurrentModificationException...

Let's squash into a single commit.

[som-snytt]

We know deferredOpen is finally empty because isPast(namerPhase) so that forcing can remove but not add to deferreds.

I confirmed that this is not the longest pos test name.