We're building these one byte at a time, we know the length.
1.98s

For now we're still using strlen, but we can avoid the call for
the common case of zero-length returns.

2.1 seconds.

This should avoid angering Coverity.

Also, no, Coverity still doesn't know from recursive mutexes.

Thanks coverity!

They're all from accessing list values outside of a lock.
Lock the list earlier to include these.

Also, does this mean it knows they're recursive now?
Let's find out!

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.