Make portals the default

GTK has recently made portals the default: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7932. Would be really nice if Qt followed that as that makes cross-DE experience better.

They use it for the following:
1. Getting DE settings on Wayland (instead of gsettings)
2. Inhibiting screen saver (instead of GNOME/Xfce-specific APIs)
3, Session management (instead of GNOME/Xfce-specific APIs)
4. File dialog via the legacy GtkFileChooserNative API (the non-legacy GtkFileDialog API uses portals for that since introduction in GTK 4.10)
5. Opening URLs/files (instead of their own mime-apps-spec implementation in glib, they never delegate that to binaries like xdg-open)
6. Print dialog
7. Sandbox friendly clipboard

Impls: https://gitlab.gnome.org/search?search=gdk_display_should_use_portal&nav_source=navbar&project_id=665&group_id=8&search_code=true&repository_ref=main

Qt uses portals for the following:
1. File dialog
2. Opening URLs/files

Using them by default for file dialogs would let Qt to use the file dialog provided by the DE without DEs implementing plugins for Qt (KDE, LXQt and Deepin seem to be the only ones doing that) thus greatly improving the integration.

Using them by default for opening URLs would make apps to be launched by systemd or dbus daemon thus following the session environment variables rather than app ones (e.g. the app setting QT_QPA_PLATFORM=xcb to run via xwayland and then it uses QDesktopServices which opens other Qt app and it runs via xwayland too leading to subpar experience) and use the portal's default handler mechanism that allows the user to select the default handling app for a file extension via interactive app choosing dialog, it saves the choice after first three attempts and does that per-app thus allowing the user to have per-app default handlers.

The classic (non-portal) way handling opening URLs/files, the out-of-the-box defaults are frequently random as DEs rarely provide a default mimeapps.list.

Switching opening URLs to portals should be as simple as just removing checkNeedPortalSupport from qgenericunixservices.cpp and always calling the logic it guards.

Switching file dialog is perhaps more involved as it currently relies on some other native dialog implementation to fallback to in case of error thus likely leading to nothing instead of a file dialog in a error case running in an environment without other native dialog implementation (e.g. WM-only environments). It should get a way to fallback to non-native dialogs. An other option is to let it to always fallback to a e,g. gtk file dialog. Or replace the portal file dialog implementation with GtkFileDialog which already handles that case gracefully by showing a dialog that the system is misconfigured.

The guard for portal file dialogs is checkNeedPortalSupport in qguiapplication.cpp