Implement Wayland-compatible eyedropper using XDG Desktop Portals

[filip-hejsek]

This PR adds a new XDG Desktop Portal-based eyedropper implementation for Linux.

The Portal-based dropper has the following limitations:

• It doesn't work if Desktop Portals are not properly installed or configured on the system (this may affect users on old or less maintained distros, those using more obscure desktop environments, or users with custom setups).
• The functionality is not equivalent to the current dropper: The current dropper captures a 7x7 area around cursor, but the Portal API only gives us the color directly under cursor.

For the vast majority of users on Linux, this is an improvement over the current dropper, which:

• is broken on wxGTK3 with X11 (the color picker works exactly once, i.e. if you pick the color a second time, the screenshot it takes is just the same as the first one until you restart Aegisub).
• doesn't work on Wayland at all, not even XWayland (this is unfixable because of Wayland security model).

Implementation notes:

• I added some new files so I had to put some copyright notice there. I copied the notice from other files, but changed the copyright statement to Copyright (c) 2026, Aegisub contributors and updated the project URL to https://aegisub.org/. I noticed the copyright notices in most files are incorrect (they were not updated when the file was modified).
• I put some things I added into a new agi::xdp_utils namespace. Not sure if this matches current conventions, although existing use of namespaces seemed inconsistent to me anyway.
• I added an #ifdef around xdg_desktop_portal_utils.cpp, even though it's unnecessary because the file is compiled conditionally. This matches how it's done in the audio_player_* files.
• I remember encountering off-by-one errors (where using the eyedropper on the current color preview would give a slightly different color), but I was unable to reproduce it.
• If invoking the color picker fails, no feedback is provided (nothing happens when the button is clicked). Displaying an error message would be better.
• There is a (very unlikely) possibility that the dialog could be closed before the OS returns the color from the Portal API. This case is not handled correctly in the code, it just sends an event to a dangling pointer.