IRMover: Account for matching types present across modules

Summary:
Due to uniqueing of DICompositeTypes, it's possible for a type from one
module to be loaded into another earlier module without being renamed.
Then when the defining module is being IRMoved, the type can be used as
a Mapping destination before being loaded, such that when it's requested
using TypeMapTy::get() it will fail with an assertion that the type is a
source type when it's actually a type in both the source and
destination modules. Correctly handle that case by allowing a non-opaque
non-literal struct type be present in both modules.

Fix for PR37684.

Reviewers: pcc, tejohnson

Reviewed By: pcc, tejohnson

Subscribers: tobiasvk, mehdi_amini, steven_wu, llvm-commits, kcc

Differential Revision: https://reviews.llvm.org/D47898

llvm-svn: 335145