We could support this in the future but right now it's causing problems.
There's also a potential ambiguity issue here where a protocol and class
could have the same name.
In addition to updating the importer, remove the two entries from the
CryptoTokenKit API notes that were trying to use this feature.
rdar://problem/27990168
More generally, an unavailable initializer shouldn't stomp on an
available initializer, because it's possible that (for example) a
designated initializer will be unavailable but a factory initializer
will be available, so one still construct objects of that type.
Fixes rdar://problem/26238032.
It's possible for swift_name to make a global declaration into a
member of another entity that has not been seen yet. In such cases,
delay resolution until the end of the translation unit (module). Fixes
the rest of rdar://problem/25502497.
Some of the callers to importDeclContextOf could and should have
passed an effective context, but didn't, so (e.g.) an enum defined in
C couldn't be mapped to a nested type in Swift. Eliminate the
single-argument importDeclContextOf honeypot so we remember to pass
down the effective Clang context. Fixes rdar://problem/25502497.
