Logging: Add more Information to `qt.qpa.plugin: Could not load the Qt platform plugin "somePlugin" in "" even though it was found.`

With the linux world gradually being dragged kicking and screaming into transitioning towards Wayland, and all the bugs in various Desktop Environments that are available that have come as a result of delaying this too long, and personally with my working on multi-user systems at work, systems with NVidia proprietary drivers, personal systems, all with different packages installed, and then throw in the complications of containers, flatpaks, AppImages, snap packages - it's been fairly common for me to receive an error of the form:

```

qt.qpa.plugin: Could not load the Qt platform plugin "somePlugin" in "" even though it was found.

```

when launching a Qt program over the last few years.

I recently became aware of the ability to set `QT_DEBUG_PLUGINS` to `1` to get a bit more information, but even then, this has not given me enough extra information to diagnose the problem. I have got DEBUG-level messages out of the QPA internals, such as:

```
QFactoryLoader::QFactoryLoader() ignoring "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3" since plugins are disabled in static builds
```
but, with this, I am no closer to seeing the fatal conditional branch where the plugin decided it was not able to start itself up.

The message is usually the same, however, the reasons causing the problem behind it can be diverse:

• DISPLAY not set appropriately on X
• XAuth problems
• XDG_RUNTIME_DIR not set, or path does not exist/do not have permissions on wayland
• Can't write to a socket
• For flatpak/snap, I am not familiar with the full detais, but appropriate APIs need to be enabled in the permissions management.

Searching through the bugs here, I see a variety of disparate issues with the same search phrase, which I think indicates the scope of issues that can produce this message, and that people attach this phrase to their bug reports as the main piece of logging information they've been presented back with.

There are some times when I get a bit mor info from the plugin itself, however, often this is the sole real error message I get out of QPA. Afraid I don't have any examples ot hand right now, because this tends to occur for me when I am right in the middle of something else, but I can begin saving these to a file somewhere and add to this bug report.

Therefore, I'd like to suggest that the logging verbosity be increased by default when QPA produces this particular message. Just on my own systems, there are so many unrelated reasons the platform plugin might not be loaded properly, I have to take a random guess at what the real issue is. I'd like it if Qt could provide more information about

• what the plugin expected,
• what it did not get successfully,
• and perhaps which other plugins were tried and in what order.

Without knowing the architecture of QPA or having read the sources just as I type this, I can only guess that something in the core QPA loader has to decide in what order to try loading the plugins, and then, when a plugin detects it can't load itself, it needs to report an error back to the main QPA library in some manner. I think, if at the point QPA finds it can't load any plugin, it could retrieve details about what that error was from each of the failed plugins in the list (that did not fail for trivial immediate reasons, such as a build that supports wayland as well as X11 being installed on a system with exclusively X11), and include these in the error message, that would go some way to helping end-user system administrators work out what it i that is wrong with their current setup and then what thread to pull on to try and fix it.

Thanks!