When a split is created from a menu action, the focus is lost before the
split is made which prevents the surface from having the
unfocused_widget. Move the logic to add the unfocused_widget to the
overlay to an exported function which is called when the split is
created.
Refactor the GTK unfocused split code to use a GtkDrawingArea widget to
dim the unfocused split. The GtkDrawingArea is added to the overlay and
a CSS style is used to give it a background color and opacity. This
aligns with the macOS design of drawing on top of the surface. In GTK,
we don't need to actually draw a rectangle because we can apply CSS
directly to the widget.
Add a class to the GtkNotebook which holds our tabs so we can more
precisely set the background color of just this `stack`. A collision was
occurring with the menu widgets, which are also a `stack`.
For a long time, us GTK users have been subject to lesser UX by not
knowing which split was focused. Improve the GTK UX by implementing both
unfocused-split-opacity and unfocused-split-fill. This is implemented by
setting the background-color of the notebook stack, and conditionally
applying a new css class "unfocused-split" to the unfocused split.
When GTK 4.14 released, it used ngl by default with GSK_RENDERER. It
leads to destroy VAO state when we closed tab or detach tab. It handles
it incorrectly with opengl's engine.
This is a fix for that issue.
Fixes#1802
This allows `keybind` configurations to map to any Unicode codepoint. This enables keybindings for which we don't have a registered keycode or for custom keyboard firmwares that may produce arbitrary text (but the Ghostty support is limited to a single codepoint).
The `keybind` syntax is unchanged. If a bound character doesn't map to a known logical key that Ghostty knows about, we map it to a Unicode codepoint. The unicode codepoint is compared against the _unshifted codepoint_ from the apprt key event.
Note that this binding is to a single _codepoint_. We don't support arbitrary sequences of characters or multi-code point graphemes for keybindings due to the complexity in memory management that would introduce.
This also provides a good fallback for scenarios where it might make sense to educate Ghostty about a key code or fix a bug in our keyboard input system, but the unicode data is correct. In that scenario, unicode key binds should allow key binds to still work while we investigate the input issues.
Example:
```
shift+ö=text:hello
```
This now works as expected on a US hardware keyboard with the Hungarian keyboard layout.
