[cxx-interop] Allow Swift extensions to access non-public C++ members

[j-hui]

This patch begins to implement the feature pitched on Swift Forums: https://forums.swift.org/t/feature-proposal-accessing-non-public-c-members-from-swift/76116

rdar://137764620

[j-hui]

This is still a draft PR. It currently builds and successfully compiles a small Swift project that reads a private integer field in a C++ class.

Still missing:

• import non-public methods into Swift
• sanity checking and diagnostics for malformed __swift_attr__
• import non-public static functions into Swift
• import inherited non-public members into Swift
• handle nested non-public inheritance
• import non-public nested classes into Swift
• import non-public nested enums into Swift
• import non-public typedefs into Swift
• tests, tests, tests! (does not block review, though helpful)
• code formatting (does not block review)
• write le documentation

Open questions:

• how/whether to support nested annotations
• bike-shedding on what the attribute and macro should be named

Side quests (out of scope, but might be nice to fix while I'm at it):

• Handle importing multiply inherited members with overlapping names

[j-hui]

@swift-ci please smoke test

[j-hui]

@swift-ci smoke test

[j-hui]

@swift-ci please smoke test

[j-hui]

@swift-ci please smoke test

[j-hui]

@swift-ci please smoke test

[j-hui]

Marking this as ready for review, but it's still missing a few tests:

• thoroughly test (possibly nested, possibly multiple) non-public inheritance
• thoroughly test non-public nested class definitions
• test out the sanity checks and diagnostics I wrote
• test out non-public union members
• some executable tests (just to make sure that things work past access checking, which happens in semantic analysis)

[Xazax-hun]

I have not looked at the tests yet as there are some TODOs around there, but the code changes look good to me so far.

[egorzhdan]

Overall the approach looks great to me! I only have a couple minor comments.

[egorzhdan]

I think I would prefer having a few (mostly) copy-pasted types over these macros, since the macros make it harder to debug test failures and make small incremental changes to the tests.

[j-hui]

I agree with the sentiment you express and inlined some of the other macros I was using.

However, I actually ended up keeping these specific overrides because the visibility of members here should actually behave exactly the same whether the record is a struct or a class, and whether the members are private or protected. In other words, these macros here only superficially quadruple our test coverage, because they are exercising the exact same code path in ClangImporter.

[DougGregor]

This is looking really good

[j-hui]

Superseded by #79093