This is an optional (default: blank) string that can be used to display a
file's URL(s) (e.g. FTP and/or Web URLs, using @-codes) when viewing extended
file information. I currently have this string output before the file
description.

The idea is that a sysop could set this string (e.g in their ctrl/text.ini)
instead of or in-addition-to their text/menu/download.msg file and then the
file URL(s) would be more readily displayed (not just went prompting for a
download protocol to send said file).

As an alternative to directory aliases configured in ftpalias.cfg and/or
web_alias.ini, a sysop can specify a shortcut (virtual directory name) per
directory in SCFG->File Areas. These shortcuts will appears as top/root level
directories in the FTP and Web servers for quick user access to important
directories.

The advantages (over ftpalias.cfg / web_alias.ini) are:
- one place to configure
- FILE_FTP_PATH and FILE_WEB_PATH @-codes will use the shortcut
  (usually a shorter, preferred virtual path to the directory)

* New JS file_area.dir[].vshortcut property

This appears to have been the original intention (otherwise, why call ultoa?),
but was never done. Just a usability/convenience thing, but an apparent bug.

We can't just memcpy() this because it's not a uint32_t, it's an
Atom.

It can be added back if the issue reappears.

ssh_active was never set to false anymore
channel_gone did exactly the same thing as conn_api.terminate
change read/write timeouts to zero when closing

Fixes the issue on Raspberry Pi with a 64-bit kernel with a 32-bit
userland. (I hope)

Previously, did not include the size, so was a 0x0 icon.

Again, not exhaustive, just the places I found quickly.

If ESC is pressed, clears the UIFC_XF_QUIT and aborts the exit.
Otherwise, continues exiting.

Not sure if there's anywhere else that needs the ATEXIT change to
avoid infinite exit loopage.

We don't appear to need it anymore, and it results in inconsistent
behaviour.

Basically, this allows figuring out if you can intercept and block
closing the window.

Two are AI generated, one is from a random dwarf name generator.

This allows us to detect the remote sending a FIN early and
disconnect rather than waiting until we have data to send.

This isn't actually necessary for the ones that use the socket
directly as they'll read zero bytes and terminate, but this way
it's consistent across all of them.

Another attempt to drive a stake through the heart of ticket 174

:|

On JS TLS sockets, sends over 16384 bytes would be truncated to
the next multiple of 8192 higher than half the buffer length.

This was triggered because we send chunks of 8192 bytes at a time,
and decrement the length each time through the loop.  We return
"success" when the total sent so far is higher than the length
remaining.

Fixes bug reported in #Synchronet by Accession.

Fixes msglist.js display of TDLR article reported by Nelgin

This shouldn't happen, but it does!

Since "FreeBSD" is longer than "Win32" or "Linux", we can't use
a fixed position/length here or the version number will get chopped
off.

We don't need another terminate flag.  Use atomics for the appropriate
members of conn_api now instead of the previous (incorrect) volatile.

Since we're using it in one place, use it everywhere.  While we're
here, read()/recv() of 0 after select indicates a closed connection
as well, an ensure we check terminate flags in inner loops.

This should help with SyncTERM issues where it appears to be
connected until you press a key, or it "hangs" and you have to
manually disconnect due to the connection actually having been
torn down at one end or the other.

Coverity believes that after checking that c < LZH_ROOT (636), it's
possible for (c + 1) to be greater than 65535.

This should take care of the last three overflow and truncation
concerns that Coverity has.