If a declaration provided in a Swift overlay has the same signature as
a declaration imported from the Clang module it overlays, or some
private framework that re-exports its interface through that Clang
module, the declaration provided in the Swift overlay shadows the one
imported from Clang.
To make this work for unqualified lookup, allow the shadowing rules to
kick in there as well. Make this a very narrow fix, because the
underlying problems that prevented us from doing this shadowing still
persist.
Fixes rdar://problem/35691030 and its several dupes.
Test more kinds of entities, including through serialized SIL, and
verify that other combinations work (e.g., building the overlay
against the public module but using it with the private version).
A public C module can be expressed as the combination of several
private modules at build time, where that structure is "collapsed"
into a single public module for client use. In such cases, the symbols
associated with the public module can actually be seen as coming from
the private module (e.g. at the time the Swift overlay is built),
which fools our overlay-specific hacks. When a module states that it
is re-exported via another, public module, teach semantic analysis to
treat the entity "as if" it came from the re-exporting public module.
Part of rdar://problem/34438586.
