Instead of relative, character-based position. In anticipation of
greater degrees of cursor freedom, and so that we don't have to
track invisible characters all the time.

Current era runs exclusively on v1.0 and up.

Instead of confining you to just the bottom row. 0,0 is bottom left.

Doesn't behave exactly as expected for non-zero column coordinates yet,
but all in due time.

We want to decouple drum state & semantics from term.c. But we also want
to continue showing printfs without mangling whatever the arvo side is
doing. Short of formalizing various "terminal modes", the best we can do
it assume that the main session is always in drum mode, and use that
assumption to squeeze into the actual content stream when doing printfs.

In essence, we insert the printf between the prompt and content, pushing
the content up into terminal scrollback. Both the prompt and cursor
position are maintained without knowledge of their original states.

Because this logic relies on knowing the (accurate) terminal height, and
this logic being the *only* thing in term.c that reads from the height,
we no longer initialize the terminal size with a sane height. Instead,
we set it to zero, and check for that to determine whether we're ready
to use this logic or not.

Due to the way this inserting works, trailing newlines are no longer
required from the output. For consistency, we manually add trailing
newlines when this logic cannot be used, both in the above-described
circumstance, and the less-common case of u3l_log.
This will of course need to be accounted for in all existing calls to
u3l_log, but we move that into the next commit for readability's sake.

As of dc2c990 these are redundant, and keeping them in would result
in trailing whiteline.

The result is that sometimes we call u3l_log with the empty string. We
simply want it to insert a newline into the scrollback for us. GCC
complains about this, because it leads to using an empty format string,
but we consider this sane behavior. We update the flags accordingly.

Only detects mouse clicks. Though, "9" mode seems broken, or unsupported
or something? Probably need to upgrade to "1000" mode or higher, but
that also reports scrolling events and such, which don't want to steal
from the context we're running in just yet.

No longer inserts newlines or redraws the prompt post-print, pushing
this responsibility down to drum where it belongs.

Additionally, separates the flow for dill's own output, from that of the
console application. This lets us keep the desired behavior for now, and
will ease reworking in the future.

Last-printed-line and cursor position are still kept around in dill
state, in order to respond to the relevant scry endpoints. These should
either be refactored to scry into the underlying console app, or be
removed entirely in favor of %hey.

As follow-up to 3fdef14, we now no longer store the prompt or cursor
in state. These were still used for view initialization, but it's more
appropriate to %hey the underlying console application in those cases.
The scry endpoints we remove, expecting clients that depended on them
to send a %hail instead.

Previously, these affected dill state. Now, they're equivalent to %lin
and %klr blits.

This prepares us for actually making use of multiple session in a sane
way.

Notable implicit change is that we no longer crash on an "unrecognized
duct", instead always handling it as destined for the default session.

Before recent dill changes, this wouldn't always be visible, since it
would get drawn in place of (and subsequently get overwritten by) the
prompt. Now that it displays consistently again, it should look a bit
better than just a noun dump.

This is somewhat redundant with gall's own "reloading agent" printfs,
but you know what they say: printfs don't real!

As per the note a couple lines up, +fore depends on drum semantics being
active. We can only guarantee those being present for the default
session, not for any others. So, we print a warning when appropriate.

Some of the remainder are still _presently_ unused, but point at
functionality we want to support again in the near future. The ones
removed here are either redundant or have no clear purpose.

styx and stub are both defined in lull. Having functions for dealing
with them in zuse rather than userspace is fitting.

While not a _common_ format per se, it still seems best at home in
+format, instead of on its own.

Adds the vertical position of the cursor to mirror state, and caps the
cursor movement to the edges of the known window.

Instead, rely on the console application to send whatever is needed
directly following a %clr blit.

This simplifies the behavior of individual blits, making their
implementation simpler and giving arvo more control.

This lets us write on top of existing content, instead of completely
replacing the affected row. Additionally, lets us draw starting at the
cursor position, instead of the leftmost column.

To retain the previous behavior, preface with [%hop 0] to move the
cursor to the start of the line, [%wyp ~] to clear the existing content,
and finally your %lin to render it.

%url blits are meant for "activating" urls. Of course, opening a new
browser tab from within a C program is difficult, so we don't do it.

This is still better than doing the faux activation by just printing
the url. term.c no longer really knows where/how to draw it, and it's
meant as interactive behavior rather than visual output, anyway.

This keeps the cursor position at the last %hop location. And being able
to go back to that position without relying on state is just plain
convenient.

The exception here is %nel blits, which move the cursor (down and) to
the start of the line, as expected of "new line" semantics.

The bottom line is where we draw the spinner, so we're only interested
in screen draws that affect that part of the screen (so that we may
restore it after having drawn the spinner there).

Given recent changes, redraws should be less frequent than updates, so
we lazily store the utf32 encoded line contents in state, instead of
the eagerly converted utf8 version.

Without the \r, the first couple printfs (generally, regarding replay)
would not align on the lefthand side.

That's the one line we track. If it gets drawn anywhere else, we can't
restore the overwritten contents.

To hint to developers that this form of output isn't as concrete or
reliable as they might assume it to be.

vere: windows fixes, refactoring for new terminal