[SymbolGraphGen] don't use Clang modules in the "only re-export public symbols" check

[QuietMisdreavus]

Resolves rdar://110399757

When symbols are checked for being "effectively private", there is a check to ensure that only public symbols from @_exported import modules are re-exported (to prevent internal symbols from the other module from appearing in the host module's symbol graph). However, this can mess up the "minimum access level" calculation when an underlying Clang module is present: Because there is an implicit @_exported import for the underlying Clang module, internal symbols in the Swift module are considered to be "re-exported" for the purposes of this check. This voids the previous "minimum access level" check, because in this case an internal symbol was meant to be considered for inclusion in the symbol graph!

This PR updates the "is this module export-imported" calculation by optionally forcing modules to be emitted from the same compiler, and then using this option in the above-mentioned calculation. This allows [-symbol-graph]-minimum-access-level to be used when there is also Clang code being built alongside the Swift module.

[QuietMisdreavus]

@swift-ci Please smoke test