Make the one who opens it responsible for closing it.

This is a heavily accessed value that is rarely changed and was
causing a lot of contention on vstatlock.

Down to 2.9 seconds.

Derp.

Down to 3.4s now.

Fixes issue where returning to the main menu always takes you to
the top option.

The SSH input thread is too complex to easily make this change.

Coverity thinks it can do the default case.

Thanks Coverity!

Shaves time down to 3.85 seconds.

Fixes high CPU when nothing is happening.

SUB and DIR have long had this bug, but I just noticed while playing with the
new USER keyword capabilities (specifying user numbers and/or names).

If you switched between numeric and alpha/string parameters, without restating
the ARS keyword, the keyword would could end up wrong in the parsed byte array.

Caveat: the name parameter cannot contain a space, so excludes spaces or
replace them with '.' or '_': the user's alias will match.

This fixes issue #748

Work-around for issue #861

This is the utility script for maintaining file bases, if you didn't know. :-)

This shaves off another .75 seconds, and gets rid of the last
glaring plateau in the stack flamegraph.

What's interersting is that I'm seeing my CPU utilization drop now
too, which implies I've reached the speed of the pty connection
type, or the speed of the term worker loop.  Maybe I'll look there
next, but since the pty isn't a major use-case for SyncTERM, I may
not... at this point it's just benchmark golf.

This was the only standout issue when profiling the ANSI parsing
code, and is a trivial fix since we're pretty much only checking
contiguous ranges of characters.

Unfortunately, I didn't create a test for comparison here.

Still massaging more speed out of it.

Down to 4.7s now... 38× faster.
Starting to get somewhere useful now.

Fixes issue where the screen would be weird during the connecting
phase.

This way, when a character overwrites, we can detect it.
Also, document the various magic colour bits.

Since we update the bitmap before drawing a frame now, we can just
mark the cells incorrectly moved by advancing the bitmap ringbuffer
as dirty and known they'll be redrawn.

This gets rid of the memmove on full-width scrolling, and gets us
into the 6s range.

Previously, every change would be flushed through to the bitmap, now
it only flushes before a frame is sent to the driver, or when specific
things (like setting pixels) occur.

This about doubles the throughput again, running the test at 11
seconds (started at 179).  At a 16× speedup now from when I started.

This can now display at about 10Mbps, which is still kinda slow,
but at least it's not completely terrible anymore.

This could likely be improved by better timing of the frame
generation... it tries to hot 100Hz right now, which is a bit
excessive.

1. It never saved the rows value set by the user
2. It would not set the current online user values immediately
3. It would only call console.getdimenions() when *both* values were set

Previously, if either of the user terminal dimensions was set to a auto (0)
then we wouldn't propagate the other specific (non-zero) value to the runtime
console dimension. Usually a user will set either both values (cols and rows)
to 0/auto or neither. So this isn't a oft-used configuration combo.

e.g. [can|is]_subject_something() is now named subject_[can|is]_something()

No functional change.

temp_cmd() should've been called first on any sane platform. <shrug>