This teaches ClangImporter to synthesize conformances of C++ iterator types to `UnsafeCxxInputIterator` protocol from the `Cxx` module.
We consider a C++ type to be an iterator if it defines a subtype (usually a typedef or a using decl) called `iterator_category` that inherits from `std::input_iterator_tag`.
rdar://96235368
This will fix modularization issues caused by the presence of Glibc and libstdc++ in a single context.
Some Glibc headers were getting hijacked by the libstdc++ module, and the decls in them were incorrectly determined to be a part of libstdc++. This caused compiler errors when trying to use those decls.
After this change, we will be able to reference Glibc headers directly from the module map, without using an additional header (`SwiftGlibc.h`).
This logic is going to be extended to inject the modulemap and the header of Glibc in addition to libstdc++. It doesn't depend on the rest of ClangImporter, so let's extract it to a separate file to make incremental builds and IDE features faster.
The ObjCMethodLookupTable for protocols was not being serialized and rebuilt on load, so NominalTypeDecl::lookupDirect() on selectors was not working correctly for deserialized types. Correct this oversight.
Previously when looking up a C++ operator (e.g. `==`), `ClangImporter::Implementation::lookupValue` returned a Swift function with a generated name (e.g. `func __operatorEqualEqual`), while the caller expected the result to be a Swift operator (e.g. `func ==`).
This change makes sure that we're returning a synthesized Swift operator when looking for a C++ operator.
This fixes an assertion failure in the typechecker:
```
swift-frontend: /home/build-user/swift/lib/Sema/ConstraintSystem.cpp:1454: std::pair<Type, Type> swift::constraints::ConstraintSystem::getTypeOfReference(swift::ValueDecl *, swift::FunctionRefKind, swift::constraints::ConstraintLocatorBuilder, swift::DeclContext *): Assertion `func->isOperator() && "Lookup should only find operators"' failed.
```
The Swift build scripts pass `-sdk /` to the Swift compiler when building the Swift stdlib and the overlays, and this affects the default include paths of Clang. We need to make sure that libstdc++ path detected by ClangImporter is the same path that will be used by Clang during compilation. To do that, let's pass `--sysroot` to the Clang driver when detecting the libstdc++ path.
To inject a modulemap into the libstdc++ directory, Swift needs to know the path of the libstdc++ installation. Previously it was assumed to be `/usr/include/c++/{version}`, however, this might not be the case. For example, on CentOS the stdlib is located at `/opt/rh/devtoolset-{version}/root/usr/include/c++/{version}`.
This change teaches Swift to extract the libstdc++ include paths from the Clang driver, and fixes C++ stdlib lookup on CentOS.
rdar://93341210
