[Dependency Scanning] Post-process imports that fail to resolve against the cache entries added by other resolved imports

[artemcm]

It is possible that import resolution failed because we are attempting to resolve a module which can only be brought in via a .modulemap of a different Clang module dependency which is not otherwise on the current search paths. For example, suppose we are scanning a .swiftinterface for module Foo, which contains:

@_exported import Foo
import Bar
...

Where Foo is the underlying Framework clang module whose .modulemap defines an auxiliary module Bar. Because Foo is a framework, its .modulemap is under <some_framework_search_path>/Foo.framework/Modules/module.modulemap. Which means that lookup of Bar alone from Swift will not be able to locate the module in it. However, the lookup of Foo will itself bring in the auxiliary module because the Clang scanner instance scanning for clang module Foo will be able to find it in the corresponding framework module's .modulemap and register it as a dependency which means it will be registered with the scanner's cache. To handle such cases, we first add all successfully-resolved modules and (for Clang modules) their transitive dependencies to the cache, and then attempt to re-query imports for which resolution originally failed from the cache. If this fails, then the scanner genuinely failed to resolve this dependency.

[artemcm]

@_exported import Foo
import Bar
...

Notably, if the order of imports here is reversed then an implicit module build too will fail. Any such cases that happen to build today do so out of luck of getting the import statement ordering right.

[artemcm]

@swift-ci smoke test

[artemcm]

@swift-ci smoke test