Support for third party gui providers

[WhySoBad]

Describe the feature

In my opinion it's a bit weird that the current gui elements like dialogs, donate screen and update screen are hard-coded in the backend. I think it would be nice if there was the possibility to use third party gui providers for those things which are currently done using hyprland-qtutils. The current gui elements could then be moved to a standard implementation of a gui provider similar how it's done with the share picker in the desktop portal.

The idea is that there is a standard interface for each gui element which is used by hyprland to communicate with a gui provider. It should be possible to specify a custom gui provider binary in the config (again, like it's done with share pickers in the desktop portal).

Also stuff like localization (#9949) could then be done in the gui provider rather than in hyprland itself.

An example for this interface for e.g. the permission manager dialog (#9930) looks like this:

Request: (JSON-ish, however serialization format does not matter as long as type is the first field)

{
    type: DIALOG, // type of the gui element this request is for (required)
    actions: [DENY, ALLOW_AND_REMEMBER, ALLOW_ONCE], // list of actions the gui element can return (type dependent)
    dialogType: PERMISSION, // type of dialog to show (required when type is `DIALOG`)
    binaryName: "discord", // permission dialog specific field
    binaryPath: "/usr/bin/discord", // permission dialog specific field
    permissionType: PERMISSION_TYPE_SCREENCOPY // permission dialog specific field
}

The bodies of all requests would share the type field and based on this the specific fields for the gui element can be determined.
In this example the request type is DIALOG and therefore a dialogType field is also added. Depending on the type field value, there could be an actions field containing action enum variants. The gui provider needs to return one of those actions in it's response if it's present.

Response:
If there is an actions field in the request then the last line in the stdout of the gui provider needs to be one of those actions when it exits. If there are no actions defined, the server does not expect a response and simply waits for termination of the gui provider.
Should an invalid action be returned we could either show a dialog (using the gui provider) or send a hyprland notification (probably better since when an invalid action is returned, the gui provider is probably not correctly implemented)

Why would it be beneficial

• This feature allows to customize not only the looks of the gui elements shown by hyprland but also the content. I don't like that hyprland has pre-formatted text for the dialogs etc. I think the user should be able to decide about the format, which text he wants (or doesn't want) in e.g. a dialog, etc.
• Using a different toolkit for the gui elements is at the moment not really supported. One could place a custom binary at the location where hyprland expects the qtutils but I wouldn't call this supported.
• Having this interface allows to easily scale out to have more gui elements in the future. Implementing it now where we only have three elements available should still be pretty straightforward but with every additional element it becomes more complex.

[vaxerski]

in general, I am against, and there are various problems with such an approach. Hyprland has to be able to monitor the popup. Furthermore, in the future, I want to add special properties to Hyprland-spawned popups, to make them harder to imitate.

I18n can be done (and should be done) in Hyprland.