This better matches what the clang importer does
normally, avoids a Clang issue where
`getPreprocessedEntitiesInRange` returns incorrect
results, and avoids the need to enable the
preprocessor record. This then lets us re-enable
`print_clang_headers.swift`.
rdar://102151774
Seen as @available attributes being printed with "_" in interface
generation, but fixing it in the importer means they can't leak into
anywhere else.
rdar://problem/30451293
Like NSObject, CFType has primitive operations CFEqual and CFHash,
so Swift should allow those types to show up in Hashable positions
(like dictionaries). The most general way to do this was to
introduce a new protocol, _CFObject, and then have the importer
automatically make all CF types conform to it.
This did require one additional change: the == implementation that
calls through to CFEqual is in a new CoreFoundation overlay, but the
conformance is in the underlying Clang module. Therefore, operator
lookup for conformances has been changed to look in the overlay for
an imported declaration (if there is one).
This re-applies 361ab62454, reverted in
f50b1e73dc, after a /very/ long interval
where we decided if it was worth breaking people who've added these
conformances on their own. Since the workaround isn't too difficult---
use `#if swift(>=3.2)` to guard the extension introducing the
conformance---it was deemed acceptable.
https://bugs.swift.org/browse/SR-2388
