Christopher Rogers' (good) work in 49fd5acbb2 caught places where
the Swift compiler was allowing a @class to resolve to a Swift class
even if that class had a conflicting Objective-C name, or wasn't
intended to be exposed to Objective-C at all. Unfortunately, this
broke source compatibility in projects where people were relying on
this. Restore that functionality, but only as a fallback; matching the
Objective-C name is better than matching the Swift name.
rdar://problem/56681046
The code does naive lookup of Swift types using the type name, but sometimes the Swift type we're looking for only has that name in its @objc attribute. This change makes the compiler exclude certain Swift declarations from matching even if the Swift name is the same (namely, not being available in Obj-C or having a mismatched `@objc` name) and continue to find the correct declaration without using lookup by name.
Fixes SR-4827
This enables additional tests for the ClangImporter. This found a
missing piece in the `-enable-objc-interop` work that was done
previously. Address that and enable the tests. There are now the
following failing tests on Linux:
* sdk - depends on Foundation (not hermetic, see SR-7572)
* mixed-nsuinteger - depends on Foundation (not hermetic, see SR-7572)
* import-mixed-with-header-twice - requires apple/swift PR#16022
* can_import_objc_idempotent - requires apple/swift PR#16022
* objc_protocol_renaming - requires apple/swift PR#16022
