Decide on semi-public API (QPA, QRhi) documentation strategy

Repurposed this task from 6.0 days. See options below. If we are fine with #1 then there is nothing to do from the doc tooling side. But if #2 is desired then some support needs to surface in the doc infrastructure first.

Updated description:

Currently there is one set of semi-public APIs in Qt: the QPA ones in qplatform*.h headers. The documentation for these is marked as internal. This is not necessarily a dealbreaker in practice since documentation is somewhat scarce for these classes.

With QRhi planned to become semi-public (i.e. moving from _p.h to .h headers but without compatibility promises) in some of the Qt 6.x releases, this will become a lot more important since the QRhi APIs have a vast amount of documentation. Currently all of it is marked \internal

Options:

• Just remove the \internal from the QRhi docs once the classes become (semi-)public, and manually add some sort of disclaimer (these APIs are in the gray zone, no binary compatibility, etc. etc.) everywhere

• More central implementation via some qdoc tag? This has the benefit of being applicable to QPA as well, if it is interested to make its documentation public some day

—

Original description:

"Check with doc team if it is possible to have docs generated and published for private and semi-private APIs (QRhi, QPA, etc.) "

Action point from Qt Contributor Summit 2019: Check with doc team if it is possible to have docs generated and published for private and semi-private APIs (QRhi, QPA, etc.)

https://wiki.qt.io/Qt_Contributor_Summit_2019_-_QtGui_RHI_3D