dankamongmen
normalize sixel max geometry when visual area geom changes
Whenever the pixel geometry changes, we ought fire off a sixel max geometry change request to match it. This ought only be done for terminals on which we intend to use Sixel, though it ought be safe on all. Send each one followed by a request for the max sixel geometry, to update our concept of it. note that this answer will be received asynchronously, which will cause some real problems with anyone trying to use it...ugh.
see #2140 for some background.
as a special case, we ought at the very least attempt to maximize the sixel graphic area on program startup, sending it along with our other initial commands if the ioctl() succeeded.
you know, we know by the time of resize whether there's XTSMGRAPHICS support, because we issued one in the beginning. resizes ought be rare events, and are fundamentally associated with disruption. maybe we just go ahead and block on an RTT on a true geometry change? send the XTSMGRAPHICS, and (if the viewing area got bigger) wait on the reply for confirmation. there's then no weird race regarding truth.
From my understanding this makes it impossible to draw (with sixel) anything that is larger than what the terminal initially reported. New sixel geometries are not queried on resize, and when drawing, the geometry is clamped to these initial values.
