Issue Description:

C++ types can appear in Swift mangled names, for example, when a C++ type appears in a function parameter list. We should validate that we mangle these C++ names correctly. For example, we should include all namespaces (including inline namespaces) and containing types into the mangled name, regardless of how the C++ type is imported into Swift.

Note that the rules on nested types differ between C and C++. For example, the following is valid C code:

struct Outer {
  struct Inner { int x; } inner1;
};
struct Inner inner2;

meaning that the name struct Inner is defined in the global namespace, despite being lexically nested.
In C++ though we must use the struct Inner like this:

Outer::Inner inner3;

meaning that the name struct Inner is indeed nested.

The implication is that the following code is valid C++ but not valid C:

struct Outer {
  struct Inner { int x; } inner1;
};

struct Outer2 {
  struct Inner { long x; } inner1;
};

Today, in C/Objective-C interop mode, Swift mangles struct Inner as if it was a Swift name __C.Inner.

This leads us to a conundrum:

• on one hand, we would like to continue mangling struct Inner as before, to keep ABI compatibility.

• on the other hand, we would like to mangle struct Inner as __C.Outer.Inner to distinguish multiple nested structs with the same name in C++. Implementing that requires us to break ABI.

Of course, this issue only applies to structs declared in the global namespace. Structs that are declared in a C++ namespace are not affected, because they could not have been visible to Swift code before, so there is no ABI compatibility to preserve.

Another point is that we only absolutely need to preserve binary compatibility on Apple platforms that have declared ABI stability. On Linux, for example, we could theoretically change the mangling, and have it diverge from mangling on Apple platforms (very unfortunate, but possible).