Research modern QSplashScreen replacement

QSplashScreen is hard to use correctly (see QTBUG-119225), because it's a QWidget and needs to live in the GUI thread, which is exactly the thread that's busy with initialising the rest of the application.

Also, it's not implemented using the native Splash Screen functionality that is available on mobile platforms, such as https://developer.android.com/develop/ui/views/launch/splash-screen

The native splash screen solutions on mobile platforms are often static assets, shown by the OS before the app is loaded, making QSplashScreen a non-starter.

We already support these static splash screens to some degree via our qmake and CMake APIs, but perhaps it's time for a cross platform and build system supported solution for static splash screens?

Android

Could be a static asset, provided as a special resource, perhaps even on build system level, and then hooking into https://developer.android.com/develop/ui/views/launch/splash-screen

iOS

Similar to Android: https://developer.apple.com/documentation/xcode/specifying-your-apps-launch-screen?language=objc

macOS, Windows, Desktop Linux

On desktop systems, the splash screen might not just be a static image, but might show the status of loading/initializing the application. They might even have a minimum level of interactivity (e.g. to at least hide the splash screen). For that, we need to process events and handle interactions, which today is very clumsy with QSplashScreen in Widgets (and no solution in Qt Quick).

Making sure that the UI is visible can be done by having it live in a dedicated thread (requires some basic UI-framework set-up on all platforms, we can't use QWindow or QWidget). The main thread updating the splash screen is then comparatively easily done through a bunch of setters or slots (with appropriate locking, if we can't use Qt's event dispatcher for the splash screen thread).

If the application needs to be able to handle custom interactions, then those handlers either need to run in that dedicated thread, or the application has to process events anyway (e.g. to have queued signal emissions processed).

One important consideration here is that most desktop apps don't have or need splash screens (photoshop or game-style loading screens), so if an app adds a static splash screen image for their mobile targets we may not want to show that on desktop as well unless explicitly asked to by the app developer. 

Embedded Linux

For a device, a splash screen would be shown when booting the device (before Qt is able to render). It is often a short image sequence providing a start-up animation.