Respect portal configuration for find_all_portal

[kennylevinsen]

The settings portal is discovered using find_all_portal_implementations, which looked for any portal that provided the implementation, regardless of configuration or UseIn=.

The new portal configuration allows us to specify which portals should be considered for each interface. Update find_all_portal_implementations to respect the configuration.

Fixes: #1017

[columbarius]

Fixes a random delay in gtk applications when the graphical session is started.

[matthiasclasen]

It is intentional that this this code uses all available settings backends.

See 013c117

[columbarius]

Doesn't the merging require an order? And do the settings implementations carry undocumented privat options for their toolkit?

[kennylevinsen]

It is intentional that this this code uses all available settings backends.

Indeed, but this also predated our ability to configure this by around 4 years. Being consistent and using the new system here as well seems to be an improvement in line with the original intent. Is there something we lose by allowing the Settings portal backends to be configured?

Some primary points supporting it:

1. Some backends, like GNOME, do not function at all outside of their environment. At best they will spam errors, at worst they cause user issues. The failure to launch could in this case be considered a GNOME bug, but requiring every portal to work everywhere is not necessarily what we want either.

2. You may wish to have a specified precedence (for Read) or ordering (for ReadAll). Likewise, you might not want GNOME settings to apply under KDE or sway at all, even for Gtk applications. Likewise, backends like Darkman substitute functionality from other backends. You might want to use such provider under e.g., sway and hyprland, while letting GNOME have its own control there.

3. Our new system allows us to have the old behavior (with a simple wildcard) and consistent user control, so it seems like a win for everyone.