SI-8010 Fix regression in erasure double definition checks

Calls to `Symbol#info` during scope iteration considered harmful.

Looks like calling `info` during this Scope iteration is triggering
the ExplicitOuter info transformer, which "makes all super accessors
and modules in traits non-private, mangling their names.". This name
change necessitates a rehashing of the owning scope, which I suspect
is enough to corrupt the ScopeEntry-s being traversed in
`checkNoDeclaredDoubleDefs`.

The upshot was that we encountered the same symbol twice, which was
reported as being a double-definition.

This problem only showed up after 086702d8a74, which did nothing
worse then change the order in which `{e, e1}.sym.info` were
forced.

I inspected SymbolPairs/OverridingPairs which *appear* to be immune
as they only test flags during scope iteration; infos are not used
until later, at which point we're iterating a temporary scope that
isn't part of the type of the owner of the symbols.
SI-8029 Avoid multi-run cyclic error with companions, package object

The bug report suggests this problem only became visible in the
IDE *after* 2.10.3, but I tested an IDE with exactly 2.10.3 and
saw the same problem.

In fact, my test case fails as far back as 2.10.0. I suspect the
problem showed up after 816cecf9a9, which checks that pairs of
companion symbols are codefined eagerly in Namers.

This commit modifies the check of `rawInfo ne NoType`
in `isCoDefinedWith` to avoid triggering adaptation of types from
the previous run. I'm not sure of the precise intent of that check.
I looked at c9861cd198 (genesis of isCoDefinedWith). Before that we
get back to 3761cb4b3a1 (the dawn of Subversion.)
[backport] SI-7439 Avoid NPE in `isMonomorphicType` with stub symbols.

`originalInfo` can return null for stub symbols; deal with that
as we used to before a regression in 016bc3db.

After this change, we can once again delete A_1.class and still compile
code instantiating B_1. (A_1 is only referred to in a method signature
of B_1 which is not called from our code.)

	scala> new B_1
	warning: Class A_1 not found - continuing with a stub.
	res0: B_1 = B_1@5284b8f9

In practice, this situation arises when someone uses a third
party class that was compiled against other libraries not avaialable
on the current compilation classpath.

(cherry picked from commit a95432168204964e4f6c4571e781559c1640f2d8)
Merge pull request #3223 from retronym/ticket/8010-2.10.x

SI-8010 Fix regression in erasure double definition checks
Merge pull request #3230 from retronym/backport/7439

[backport] SI-7439 Avoid NPE in `isMonomorphicType` with stub symbols.
Merge pull request #3229 from retronym/ticket/8029

SI-8029 Avoid multi-run cyclic error with companions, package object