Massage Qt Quick on RHI for the substandard VMs of the CI

Currently we choose one QRhi backend and attempt to do QRhi::create() with that, and then fail if that did not succeed.

For the autotests in the CI VMs this is not quite ideal. There are two problems:

• a macOS VM will typically not have Metal, even though Metal is our primary choice (and the only really supported in Qt 6) on that platform. To run any test, it needs to fall back to the OpenGL backend...

Note that one cannot just implement "fallbacks" between different graphics APIs. The QQuickWindow is tied to the graphics API as well! So what is decided at QQuickWindow construction time is the only option, it cannot change afterwards.

So for macOS in particular is could be that a special probing step is needed.

• Initializing the D3D11 backend with the default settings may fail in the VM, esp. if the debug layer is requested. This we can probably handle gracefully in the QRhi backend in qtbase (retry without the debug layer if it was not successful) [this may only be a problem for tst_qrhi in qtbase in practice but needs to be fixed nonetheless]

To be confirmed if the Windows 10 VMs are running qtbase and qtdeclarative tests as expected with D3D after the above fix.

• However, the Windows 7 VM is broken completely. ANGLE does not work in it either (there are no DXGI adapters at all in that system...)

Ironically enough, the Mingw Windows 7 config is the only developer build in qtdeclarative, meaning it is the only Windows configuration that runs (or, well, attempts to run) the full autotest set.

Current proposal is to have a if-Windows-7-force-OpenGL type of check. So said Win 7 CI config would use OpenGL on Mesa llvmpipe. (eventually the Win 7 VM should disappear if we drop Win 7 support from Qt 6 but we cannot block the RHI migration waiting for that)