Better tools to document template parameter names and constraints

The documentation of our template APIs today has two major shortcomings:

• We cannot document the template parameters in the same way as we do function parameters

Ie. in QHash (https://doc.qt.io/qt-6/qhash.html), we document the type as template <typename Key, typename T> class QHash but in the description of the class we don't document Key and T, and instead just say: "QHash<Key, T> is one of Qt's generic container classes. It stores (key, value) pairs and provides very fast lookup of the value associated with a key.". It's up to the reader to figure out that T is the type of the value.

This is a bigger issue with template functions in non-template classes, where we don't have standardised wording, and also no qdoc support to make sure that we have a \a T equivalent for all template parameters.

• We have no standard way to document constraints for the template types

We increasingly SFINAE out template instances from the overload set if the type doesn't meet the requirements. As we can't use C++20 concepts yet, we do that via std::enable_if and hide that complexity from the documentation explicitly via #ifndef QT_QDOC preprocessor symbols.

E.g. a constraint today might be implemented as

template <typename T
#ifndef QT_QDOC
    , std::enable_if_t<std::is_trivially_constructible_v<T>, bool> = true
#endif
         >
void foo(T &&t)
{} 

And then the documentation will not mention that T needs to be trivially constructible.

But even without C++ concepts, we could express constraints in a way that qdoc can understand. This requires a bit of research into how to make this so that it applies also when we finally move to C++20.

In fact, qdoc could already use C++20, so we might just as well express constraints using C++20 syntax:

template <typename T
#ifndef QT_QDOC
    , std::enable_if_t<std::is_trivially_constructible_v<T>, bool> = true
    >
#else
    >
requires (std::is_trivially_constructible_v<T>)
#endif
void foo(T &&t)
{}

and that way start building a concepts library already now, that qdoc can then refer to. Once we move to C++ 20, we will have a good starting point as well as good documentation.