[clang][NFC] Add test for CWG issues about linkage in cross-TU context (#113736)

[CWG279](https://cplusplus.github.io/CWG/issues/279.html) Correspondence
of "names for linkage purposes"
====================

[P1787R6](https://wg21.link/p1787r6):
> CWG1884, CWG279, and CWG338 are resolved by defining entity identity
explicitly.

In both cases discussed in the issue, declaration matching succeeds per
[[basic.link]/8](https://eel.is/c++draft/basic.link#8), thanks to the
> considering declarations of unnamed types to introduce their names for
linkage purposes, if any ([dcl.typedef], [dcl.enum])

and

> they both declare names with external linkage

parts. Which means that both pairs of declarations of `S` and `S2`
declare the same entity.
[[basic.link]/11](https://eel.is/c++draft/basic.link#11) is also
satisfied, because in all cases type is declared.

Then cases diverge. `S` is a pair of a forward declaration and a
definition, which means it's not a subject to
[[basic.def.odr]/15](https://eel.is/c++draft/basic.def.odr#15), hence
it's well-formed. Whereas `S2` is a pair of two definitions, so they are
subjects to
[[basic.def.odr]/15](https://eel.is/c++draft/basic.def.odr#15), which
they do not satisfy due to the violation of the following requirement:

> — Each such definition shall consist of the same sequence of tokens,
<...>

Because per [[class.pre/2]](https://eel.is/c++draft/class#pre-2), class
definition is class-specifier, which includes class-head, but class-head
is different between definitions.



[CWG338](https://cplusplus.github.io/CWG/issues/338.html) Enumerator
name with linkage used as class name in other translation unit
====================

[P1787R6](https://wg21.link/p1787r6):
> CWG1884, CWG279, and CWG338 are resolved by defining entity identity
explicitly.

I believe this CWG issue points to the same underlying issue with old
[basic.link]/9 as CWG1884 (see below), so I'm calling it a duplicate of
CWG1884. Cases described there are a part of an extensive CWG1884 test.
Also worth noting that enumerators don't have linkage these days.



[CWG1884](https://cplusplus.github.io/CWG/issues/1898.html) Unclear
requirements for same-named external-linkage entities
====================

[P1787R6](https://wg21.link/p1787r6):
> CWG1884, CWG279, and CWG338 are resolved by defining entity identity
explicitly.

[basic.link]/9 quoted in the issue is now split into several pieces.

> Two names that are the same (6.1 [basic.pre])

I believe this is corresponding declarations now, defined in
[[basic.scope.scope]/4](https://eel.is/c++draft/basic.scope#scope-4).

> and that are declared in different scopes shall denote the same
variable, function, type, enumerator, template or namespace if

This is covered by
[[basic.link]/11](https://eel.is/c++draft/basic.link#11) after it's
determined by [[basic.link]/8](https://eel.is/c++draft/basic.link#8)
that two declarations declare the same entity.

> — both names have external linkage or else both names have internal
linkage and are declared in the same translation unit; and
> — both names refer to members of the same namespace or to members, not
by inheritance, of the same class; and

Most of this is covered by
[[basic.link]/8](https://eel.is/c++draft/basic.link#8).

> — when both names denote functions, the parameter-type-lists of the
functions (9.3.4.6 [dcl.fct]) are identical; and
> — when both names denote function templates, the signatures (13.7.7.2
[temp.over.link]) are the same.

This is corresponding overloads now, defined in
[[basic.scope.scope]/4](https://eel.is/c++draft/basic.scope#scope-4).

> Among other things, it should be clarified that "declared in" refers
to the namespace of which the name is a member, not the lexical scope in
which the declaration appears (which affects friend declarations,
block-scope extern declarations, and elaborated-type-specifiers).

This is addressed by "have the same target scope" part of
[[basic.link]/8](https://eel.is/c++draft/basic.link#8).

The tests basically test
[[basic.link]/11](https://eel.is/c++draft/basic.link#11) from the
following standpoint:
> The intent is that this rule prevents declaring a name with extenal
linkage to be, for instance, a type in one translation unit and a
namespace in a different translation unit.

See the comment in the beginning of the test for details on testing
approach. Reviewers are advised to check compiler output for any
surprises, but if they are in a hurry, they can search for `FIXME`,
`OK`, and `#cwg1884` to see the most of irregularities in Clang behavior
across the test (not all of them are incorrect behavior, though).

Author: Endilll