Setup and harvest secondary clang resources

[compnerd]

Description

We currently do not setup a static resource directory for clang (i.e. $(ImageRoot)\Toolchains\$(ProductVersion)+$(ProductVariant)\usr\lib\swift_static\clang). While we can currently get away with this as we are only installing the headers, it is unclear if we can simply replicate the content when the sanitizer and compiler runtimes are populated and considered for building.

Additional information

No response

[etcwilde]

I wonder if we can solve this by having an actual compiler resource dir that doesn't contain a bunch of SDK content?
The clang-importer resource headers are tied to the compiler build, not the SDK and don't really need to change between the static and dynamic runtimes.

This means we need to fix the semantics of the -resource-dir flag though.
Maybe usr/lib/swiftc/include/clang/...?

[compnerd]

I do agree that the semantics of -resource-dir need to be cleaned up. I think that we should actually split up -resource-dir and introduce a -clang-resource-dir for the Swift compiler allowing us to isolate the clang resource directory from Swift's.

However, the SDK content is however tied to the headers - library evolution does not hide SwiftShims from the client. This inverted dependency is annoying and perhaps we can identify a way to repair this without the circularity that is currently present.