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
...even if the base decl isn't.
This isn't normally possible, but it can come up when an imported type
is import-as-member'd onto an internal Swift declaration. This isn't
even such an unreasonable thing to do, since internal Swift
declarations are exposed in the generated header for an app.
rdar://problem/43312660
