[cxx-interop] Import non-public inherited members

[j-hui]

This patch is follow-up work from #78942 and concurrent with #79093.
It imports non-public members, which were previously not being imported.

The access level of each inherited base member is computed according to
the inheritance rules in C++, and accounts for public/protected/private
inheritance. Base members that are inaccessible from the derived class
(either because they are private, or due to nested private inheritance)
are also imported into Swift but marked as unavailable, to ensure that
(1) trying to access these members produces a reasonable error message
rather than claiming that the inaccessible member doesn't exist, and
(2) ambiguous member lookups aren't erroneously disambiguated by virtue
of one being public and the other private.

Once #79093 (SWIFT_PRIVATE_FILEID) is merged in, these inherited members
will be available within Swift extensions that have been blessed by the
SWIFT_PRIVATE_FILEID annotation.

rdar://137764620

[j-hui]

@swift-ci Please test

[Xazax-hun]

Are there any tests where a field with the same name appears in multiple bases? We can disambiguate accessing those in C++ by using qualified lookup but it is not possible in Swift where in case of structs we put everything in the same type. So I think we might want to skip fields (and methods?) that can cause ambiguities.

(This is different from the case where the members in the derived class shadows the members in the base.)

[j-hui]

Ambiguous lookups need follow-up work. Last time I tried it out, it gave me a very unhelpful error message, because the way the diagnostics are implemented don't seem to consider that kind of ambiguity.

That said, I still think we should import those ambiguous members, because it lets us report the same error from Swift as in C++ (even if that isn't quite implemented right now). This is the same reason why I am importing inaccessible private base members; without doing so, we get "missing field" errors that don't actually point to the underlying problem.

To work around an ambiguous member lookup, users can add a shim method in C++ where they perform the fully qualified lookup there.

[j-hui]

I will add a test case that has ambiguous members and make sure it does not affect unambiguous member lookup.

[j-hui]

@Xazax-hun I added a test case that checks ambiguous lookups, and it misbehaves somewhat (specifically, lookups that should be ambiguous do not seem to be).

There is also a pretty big discrepancy in how ClangImporter.cpp::ClangRecordMemberLookup and ImportDecl.cpp::loadAllMembersOfRecordDecl() deal with ambiguities, which causes the module interface suggest a different behavior that what we observe when type-checking various lookups.

To avoid blowing up the size of this PR, I would like to revisit this issue in follow-up work.

rdar://144843878

[j-hui]

@swift-ci Please test

[j-hui]

@swift-ci Please test

[j-hui]

@swift-ci Please smoke test

[Xazax-hun]

Thanks!

[j-hui]

@swift-ci Please test

[j-hui]

@swift-ci please test

[j-hui]

@swift-ci please smoke test windows platform

[j-hui]

@swift-ci please test

[j-hui]

@swift-ci Please test