This reduces the time in Vaxis.render. I ran perf several times for ~60
seconds each time on example/vaxis.zig.

Before => 15.17% in Vaxis.render
After => 14.15% in Vaxis.render

This was introduced in zig 0.14

Why didn't I do this earlier? This results in about a 20% memory savings
when testing out the examples. We have 3 arraylists per Cell, so for
each cell we now save usize * 3 = 192 bytes, for my typical full screen
terminal I have 239 x 47 cells. That's a total of 2.1Mb!

The queue was signaling a pop that's waiting for the queue to not be
empty before we had actually added something to the queue. This change
moves the signal to after the push has been done so we're not signaling
a pop with a still-empty queue.

Needed for fixing https://github.com/ghostty-org/ghostty/issues/6734

This reverts commit 3a70d898d5ef52b61f3cae03c5ebab0aa9749e05.

Squash this commit once upstream zg has accepted a PR which updates for
recent zig

Some terminals (foot, ghostty) encode shift + space as CSI 32 ; 2 u when
using the kkp disambiguate flag. We need to handle this as a printable
character. Use the logic from vaxis (the go version), which checks if
the mods were shift only and the character is printable. Then we upper
case it, set the text and the shifted char

Change the core loop for handling of mouse events. We now do a layout
phase, which calls draw on the root widget. From here, we see if the
widget underneath the mouse has changed and, if so, send mouse_enter and
mouse_exit events, then do another layout, and then *finally* we render.

This fixes a case where the mouse hasn't moved, but the content of the
screen has changed. The hover state of any widget will be updated in the
second layout phase if the app indicates a redraw is necessary from the
mouse_enter and mouse_exit events.

The lower bound must be within the parent window

Implement explicit width hint extension, developed by kitty. When
both explicit width and mode 2027 are available, we default to explicit
width. Custom event loop authors will need to update their loops to add
support for this by setting the new capability value.

For simplicity, we don't actually add a flag in the parser for checking
between a cursor position and an F3 key. Instead, we send the cursor
home, then do an explicit width command, *then* check the cursor
position. If the cursor has moved - meaning the extension is supported -
we will see an F3 key with the shift modifier. The response will be
something like `\x1b[1;2R` which we parse as a shift+F3. But in the
loop, we check the flag if we have sent queries and handle this specific
event differently.

Reference: https://github.com/kovidgoyal/kitty/issues/8226

This adds an example demonstrating the use of the ScrollView and
ScrollBars widgets. It also includes keybindings to change how the child
widgets are laid out so you can see how that affects how the scroll bars
are rendered.

The content size estimates are deliberately wrong to demonstrate how
that affects the scroll bars. The value is intended to be modified by
whoever is testing the example.

This widget is intended to wrap a ScrollView widget and show vertical
and horizontal scroll bars as indicators of scroll position in the
ScrollView. It's recommended to provide the estimated content sizes
with as much accuracy as possible for the best user experience and
performance.

If estimated content sizes are not provided the scroll bar sizes and
positions will be estimated using the size of child arrays. This is not
perfect and will cause inconsistencies if the child widgets aren't all
the exact same heights.

The widget will render its children in a container that can be scrolled
both horizontally and vertically. The widget itself does not render any
scroll bars or other indicators of current scroll position.

Since this view is heavily based on the ListView widget it inherits the
same `cursor` functionality to show the current position of a selected
widget.

Known Issues
============

1. The view currently does not enforce a maximum width on the content to
be able to correctly figure out whether the content can still be
scrolled horizontally. This will cause the widget to draw beyond its
boundaries horizontally.
2. When the last widget rendered is taller than a single row the whole
widget will be drawn. This will cause the widget to draw beyond its
boundaries vertically.