gtk: improve split sizing

[dkinzler]

This PR improves the way splits/surfaces are sized in the GTK app, which eliminates flickering and slightly improves performance.

Fixes #13328, #12709, #11187.
Related #8208 (closed) but some later comments mention flickering issues persisting.
Builds on top of the changes in #12698.

Previously an idle callback was used to sync the split ratio between the GTK widget tree and the split tree data structure that represents the split layout. The widget tree contains a SplitTreeSplit widget, which wraps a GtkPaned widget, for every split. During size allocation a GtkPaned widget first computes the initial position of the divider and thereby the size for its two children. We get notified of that position (and the max possible position) via the propPosition/propMaxPosition callbacks in SplitTreeSplit and set up an idle callback (the onIdle function) to update the position if it does not match the desired split ratio. Since the initial position is often not correct, especially in nested layouts or if the ratio is not 0.5, a surface will first be shown with the wrong size for a few frames until the idle callback runs and corrects the sizing. In nested layouts it might take multiple rounds of size allocation and idle callbacks until every surface gets the correct size. This causes flickering as widgets eventually snap to another size, which is especially noticeable if the layout changes quickly e.g. when resizing a split using keybinds.

To fix this, the divider position will now be corrected directly from the propMaxPosition callback, which runs during GTK size allocation, right after a GtkPaned computes the initial position and right before it uses the position to allocate sizes for its two children. With this change every surface will be sized correctly during the first round of size allocation.
The idle callback is still used to update the ratio in the split tree when a split is resized by manually dragging the divider in the UI. The logic to sync the split ratio was moved to the new syncSplitRatio function which is called from both propMaxPosition and onIdle.

This is kind of hacky, but I reviewed the GTK source code in detail to verify that this is safe (see the various code comments for more details). I also tested extensively on both Hyprland and KDE Plasma: creating deeply nested layouts, resizing with both keybinds and dragging dividers by hand, with multiple tabs, resizing the entire window, resizing entire subtrees to 0 and back. Everything seems to work fine.

For performance testing I used sysprof which can also collect GTK stats. When creating/deleting/resizing splits I can measure a slight but consistent increase in GTK FPS (+5 to 10) on my system. Other than that CPU usage and FPS seem to be the same before and after. I guess this makes sense, while we added a bit of work to the GTK loop during size allocation, we avoid surfaces being resized.

For the flickering, here's a side-by-side comparison. Left is before the changes, right is after.

comparison.mp4

AI Disclosure: no AI was used.

[tristan957]

Should we add some debug asserts here?

[dkinzler]

Can't hurt, added assertions for all the assumptions in the comment.

[tristan957]

I don't love to_paned. Maybe a well named enum would be easier to understand when reading the code?

[dkinzler]

Changed to use an enum, that's definitely better. Alternatively I also thought about just having a function that returns all the parameters (min, max, position, current_ratio etc.) and then doing the rest directly in propMaxPosition/onIdle, but that is also kind of awkward.