Properly cope with ordering issues when importing clang decls during extension binding

[beccadax]

Description

In #78697, we worked around a bug where binding an extension of a swift_wrapper/swift_newtype typedef before the underlying type's _ObjectiveCBridgeable extension has been bound would incorrectly make the newtype non-bridgeable. However, the fix taken here is specific to String and hardcodes knowledge that it is Foundation which makes that type bridgeable. This is probably okay since _ObjectiveCBridgeable is compiler-internal, but it would be better to find a more principled fix for the bug.

One possible way to address it would be to defer all of the logic associated with transferKnown() until later in compilation—perhaps when the list of conformances is first used—in hopes that this will be late enough that all extensions will be bound. However, it's not clear whether all of the associated logic can be delayed long enough to pull that off.

Reproduction

1. Revert Work around Foundation NS_TYPED_ENUM bug #78697's changes to SwiftDeclConverter::importSwiftNewtype() in ImportDecl.cpp, leaving the test changes intact.
2. Run the lit test ClangImporter/newtype_conformance.swift

Expected behavior

The test should pass. Instead, absent the hack added in #78697, it will fail on the z as NSString line.

Environment

First observed circa 6b2fb2e, but this bug may have been latent in the compiler for a long time since it only affects Foundation in practice.

Additional information

An alternative solution would be to make swift::bindExtensions() defer binding either extensions to Clang-imported types, or extensions which don't have "special" conformances like _ObjectiveCBridgeable, until a second pass. However, this is still a bit of a hack and it would probably incur a minor performance penalty in projects that would not otherwise be affected by this bug.

Apple engineers: see rdar://142693093 for the original occurrence of this bug.