[clang] Qualify non-dependent types of a class template with its declaration (PR #67566)

[Luca Di sera via cfe-commits]

diseraluca wrote:

>  I still do not see why the proposed solution would not work. If it solves the minimal case that you provided in the description of this PR, I am afraid that there is some bit from the Qt setup that we do not understand.

I cannot for certain say if there is an issue or not with how the Qt codebase is setup; but I think it is out of the scope of the task we are trying to solve to change that based on the behavior of QDoc interoperations with Clang.

For what it is worth, I've been playing with a very small example to check a few possibilities, and even excluding explicit specializations we still have certain cases that are not stable.

Say in

```
#pragma once

template<typename T>
class QList {
public:
	using Foo = const T&;

	void begin(Foo);
};
```

Adding something as `using Bar = QList<int>;`, and this being the only code in the translation unit, we still have the addition of such a line modifying our output, qualifying the type of the first parameter of `begin` as `QList<int>::Foo`, even with your proposal.

Say we can stabilize that, so that it always qualify in the same way, say `QList<int>`.

If we are documenting, maybe, some method `QList::Foo QList::bar()` and 
we show to the user the return type as `QList<int>::Foo`, this is going to be misleading, 
albeit not as erroneous as the `QFuture<void>` case, for our user.

Indeed, the return type of `bar` really depends on the instantiation of `QList` that we are looking at and it would be extremely confusing for a user skimming our documentation to think that it always returns a `QList<int>::Foo`.
As a documentation generator we really want to look at the generic case for our output.

Now, say we have a very stable output, albeit not adequate for our case, it might simplify doing some postprocessing to qualify in the way we want, but at that point we still need to maintain something relatively similar to `getFullyQualified*`, thus why it isn't that much of a difference for our use case to only have a more stable output.

There are some other cases that might be iffy for our use-case too, with this behavior.

Thus why I think, albeit unfortunate, our use-cases just happen to be somewhat in conflict with regards to the output of `getFullyQualified*`.

@vgvassilev  Both me an my team are deeply thankful for your help. It was really kind to try and find a solution for our case.

I will close this PR as I don't think it can be merged, as it would break other people use cases.
I will leave it open 1 or 2 days more in case someone else wants to chime in with something.

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