[clang] Ignore template parameter visibility (PR #72092)

[Fangrui Song via cfe-commits]

MaskRay wrote:

> > After the change, does it seem more feasible to ignore template parameters?
> 
> Hmm. You're right that considering the type of a non-type template argument would be enough to give the right visibility to my example. It would not be enough if the template was used as a template template argument, though.
> I suspect the code just needs to be restructured a bit to get the behavior I'm asking for, but I'll need to think about it.

The code for template template argument is from commit 7dc5c17d9228dce0d5f83d5750321753d1f83c0a (2010) and reworked by you in commit df25c435991ad751a319433c1425a1acf53c687e (2013).
Deleting the code causes no `check-clang` failure.

```
LinkageInfo LinkageComputer::getLVForTemplateParameterList(...
...
    // Template template parameters can be restricted by their
    // template parameters, recursively.
    const auto *TTP = cast<TemplateTemplateParmDecl>(P);
```

Nevertheless, here a test to demonstrate the behavior change with this patch (which will match GCC).
```
#define HIDDEN __attribute__((visibility("hidden")))
#define DEFAULT __attribute__((visibility("default")))

// namespace {
struct HIDDEN Hid {};
// }
template<Hid *h> struct A {};
template<Hid *h> struct DEFAULT DA {};

template <template<Hid *> class C> struct B {};
B<A> a;   // gcc: DEFAULT; w/o: HIDDEN; w/: DEFAULT
B<DA> da; // gcc: DEFAULT; w/o: HIDDEN; w/: DEFAULT
```

The hidden visibility from `<Hid *>` constrains `B<A>` and `B<DA>`.
If I place `Hid` in an anonymous namespace, `a` and `da` will become internal.

So I wonder whether this second-order influence is really intuitive or useful ...
`rg 'template.*template' libcxx/include/` does not reveal any non-type type parameter in a template template parameter.

As this PR shows, there's a lot of complexity for the various cases (a) class member/namespace-scoped (b) class/function/variable template.
It seems that only with some simplification will it become feasible to figure out the right semantics and address https://github.com/llvm/llvm-project/issues/16561 / https://github.com/llvm/llvm-project/issues/31462


https://github.com/llvm/llvm-project/pull/72092