Enable QRhi API usage in applications and libraries without forcing purely private APIs on them

As an application and/or library developer I want to use Qt's own 3D graphics and shader abstraction layers in my own applications and tools in a manner that is well-integrated with Qt Quick and Widgets, and does not involve having to deal with fully private APIs without any documentation in the standard Qt documentation set.

• Bump the "level" of QRhi and QShader APIs from private to a QPA-style "semi -public".
  • Meaning they are still private, i.e. one must pull in gui-private / Qt::GuiPrivate, but the headers have .h suffix and special syncqt support so one can do #include <rhi/qrhi.h>
  • Similar compatibility promise as with QPA: no source/binary compatibility, but won't break in patch releases. And we aim (although not guarantee) not to break at all.
  • However, unlike QPA, docs will be made public, i.e. no more \internal
  • It will be no longer needed to hide types such as QRhi in public headers, but including <rhi/qrhi.h> and similar in a public header still won't be possible. Forward declaring is fine. (same story as with QPA: for example, qwindow.h cannot include qplatformwindow.h, because applications not pulling in GuiPrivate would fail to compile, but it can forward declare QPlatformWindow)

• Introduce enablers in Qt Quick and Widgets that help with integrating QRhi-rendered content. These new classes are expected to be proper public APIs.
  • The low-level approach, where one uses QRhi to render into a QWindow needs at least one simple, robust, well-documented example, but this is not expected to be the primary use case for application developers. They are rather interested in augmenting their widget/Quick UI, or possibly their Quick 3D scenes, with QRhi-rendered content.
  • QRhiWidget - the modern QOpenGLWidget alternative
    • enabled by the Qt 6.4 changes to the backingstore and moving from OpenGL to QRhi-based composition
  • QQuickRhiItem - the modern QQuickFramebufferObject alternative
    • enables implementing a custom QQuickItem that does QRhi-based rendering into a texture and the item automatically draws a textured quad
  • QSGRenderNode - just needs a few new accessor functions to the currently private data so a QRhi-based subclass can be implemented without private API/data access
    • enables the "inline" style of integrating QRhi-based rendering, i.e. no separate render target
    • there is a already an example (customrendernode), using private APIs, this can now be fixed up
  • add examples for underlay/overlay (before/afterRendering signals etc.)
    • this should already be possible, but not demonstrated in any examples.
    • we have examples such as openglunderqml, vulkanunderqml, etc. now we should also have rhiunderqml
  • check what's needed for QQuickRenderControl, so that we can make a proper public example that only uses public Qt Quick / semi-public QRhi APIs to do offscreen rendering of a Qt Quick scene into a cross-platform QRhiTexture and then reads back and saves the images to file, or perhaps shows the generated images in a grid in a widget-based user interface
  • some public Qt Quick APIs that are currently marked as \internal because they refer to QRhi and QRhiRenderTarget can now become publicly documented