Dependencies Scanner: report compiled Swift module paths if they are available

[nkcsgexi]

For the explicit module mode, swift-driver uses -compile-module-from-interface to
generate modules from interfaces found by the dependency scanner. However, we don't
need to build the binary module if up-to-date modules are available, either adjacent
to the interface file or in the prebuilt module cache directory. This patch teaches
dependencies scanner to report these ready-to-use binary modules.

[nkcsgexi]

@swift-ci please smoke test

[nkcsgexi]

@swift-ci please smoke test

[nkcsgexi]

@swift-ci please smoke test

[nkcsgexi]

@swift-ci please smoke test

[nkcsgexi]

@swift-ci please test

[nkcsgexi]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 4cbf85da919c7677d75e85f2b84627dffd53ac5d

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 4cbf85da919c7677d75e85f2b84627dffd53ac5d

[DougGregor]

I'd like to talk about this approach a bit more. My mental model is that the fast dependency scanner should not make any decisions about what is up-to-date and what isn't. Rather, it should model all of the relationships that can exist between the various sources and compiled products, and let the build system decide what is "up-to-date".

[nkcsgexi]

@DougGregor , @artemcm and I were having a discussion about this and I'm now convinced that reporting only the ready-to-use binary modules is omitting information build systems can later reuse. I'll land additional commits to: (1) reporting candidate ready-to-use binary modules for a Swift interface from the dependency scanner, (2) -compile-module-from-interface should take these candidate modules as explicit module inputs, and (3) -compile-module-from-interface should emit a forwarding-module to a candidate module if it's up-to-date by checking content hash.