Annotate _FoundationCShims as a system module

[egorzhdan]

This fixes Clang modularization errors coming out of the Swift compiler when building Swift code that uses C++ interoperability on Linux:

/usr/include/c++/v1/istream:198:5: error: 'std::basic_istream<wchar_t>::basic_istream' from module 'SwiftGlibc' is not present in definition of 'std::wistream' in module '_FoundationCShims'
 196 | protected:
 197 |     inline _LIBCPP_INLINE_VISIBILITY
 198 |     basic_istream(basic_istream&& __rhs);

Two observations:

1. _FoundationCShims does not list all the headers that it includes in the modulemap. Instead, the modulemap refers to a single headers with several #include directives. This means that a different module that includes the same headers might hijack them from _FoundationCShims, depending on compiler flags and the order of inclusion in the translation unit.

2. Some of the headers that _FoundationCShims includes are C headers that have corresponding C++ compatibility headers. When C++ interop is enabled, the C++ headers will be included. Those headers are owned by the std module.

Annotating the _FoundationCShims module as a system module suppresses the errors about these.

rdar://137044915

[egorzhdan]

@swift-ci please test

[parkera]

It’s not clear to me from the description here if we are using the system header annotation because that’s correct or to work around the other 2 issues - which would be solved differently.

[jmschonfeld]

I have a similar concern to what @parkera mentioned above.

_FoundationCShims does not list all the headers that it includes in the modulemap. Instead, the modulemap refers to a single headers with several #include directives. This means that a different module that includes the same headers might hijack them from _FoundationCShims,

I'm not sure I'm fully following on this point: AFAIK a module map is only supposed to list the headers that it defines itself, and as _FoundationCShims is an internal-only module whose headers should never be included in another module, I don't quite follow when we'd hit this situation. Perhaps we might need to update our module map to not use an "umbrella" header, but I don't think we should ever hit this "hijacking" scenario, right?