[cxx-interop] Mark clang-related requests as un-cached.

[zoecarver]

Pointers from clang appear to be unstable in some capacity. We would find the result of unrelated methods that were cached using this request. My theory is that clang loads one module, then frees its AST when it's done, or maybe just re-allocates the AST at some point. In any case, we cannot cache requests on clang pointers.

This should fix the flakeyness issue that we've been seeing for a while.

[zoecarver]

@swift-ci please test

[egorzhdan]

🤯

[zoecarver]

From the 🍒 pick:

To follow up on this: when a user imports some clang modules, clang goes off to load those modules on separate threads. Each of these modules gets its own ASTContext which is later copied into the primary ASTContext. When loading a module and writing out a PCM file, Clang invokes a customization point, where Swift builds a lookup table from the clang AST. This lookup table imports a bunch of Clang names. During this import of clang names, the ASTContext and all Decl pointers are not stable (because they are part of the non-primary ASTContext), so any caching on these pointers will lead to very odd behavior.