Fix new date editing bug in user editor: we must use the numeric format
for dates when creating strings to be edited.

No need to use time32_t for this.

"01/00/00" would get parsed/converted back to Jan-1-2000 (usually), which is
usually not what we want.

We want to not expand tilde to attributes when there are any attribute codes
in the mnemonics string. The existene of a non-attribute ctrl-a code should
not have prevented the tilde expansion.

Fix for issue #805 reported by Nelgin (thank you)

Although we've added (in SBBS v3.20) configurable numeric date input/display
formats for the system, the output was still ambiguous for users (e.g.
NN/NN/NN which could be interpretted a number of ways), so I've added an option
to choose "verbal" short date formats to be displayed where possible instead.
The same value separate from the numeric format (whatever the sysop chose) is
used in the verbal date output, but since month name abbreviations are 3
characters, only one separator is used (to keep the output length fixed at 8
characters).

The new "Verbal" short date display format is choosable in the SCFG wizard and
via SCFG->System->Short Date Format.

Currently, this is a slower way to look-up a text.dat string, but requires no
load/require of text.js and allows for a shorter syntax to get a text.dat
string, i.e. bbs.text("Quit") instead of bbs.text(bbs.text.Quit);

Although the bbs.text() ID lookup is cached, it's only marginally faster than
system.text() ID lookup, which is not cached and about 1/3 the speed of the
other methods of index to string lookup (in the MSVC-Windows build).

... with Servers->Terminal Server->Login Requirements

Updated help text: F5->Ctrl-C, no need to hand-update sbbs.ini when adding
or removing nodes (any more).

This is a code clean-up, no change in functionality

It's possible to have multiple transfer protocols with the same mmemonic, but
with different transfer types supports (which would be weird, but possible).
This allows us to use protnum() to replace a lot of copy/pasted prot looping
and comparing logic throughout sbbs.

Also added a variant of sbbs_t::quit_key() that takes and returns a string
(for easy concatenation to strings of key chars).

for use by JS bbs.xtrn_prot_menu() immediately, elsewhere soon.

... that the user has access to

So we don't have to reimplement this logic in user_settings.js (or
equivalent) any longer.

Use localizable [Q]uit key

Removed trailing whitespace

Helpful for a JS batch file transfer menu

Returns count of files removed now (not bool).

These 2 properties, specifically, could be made writable since
1. smb_t.curmsg is a special element owned by the application, not smblib
2. a special sbbs_t.current_msg_number property could be created/used to
   underlie the bbs.msg_number when there's no open message base (by sbbs).

This might be all that's needed to resolve issue #793

The other bbs.msg_* and bbs.smb_* properties are not so easily made writable,
so hopefully that's not desired.

And try to make it clear that multiple bases can be passed on the command-line.

Fix issue #801

Fix for issue #800

Other Ctrl-A codes (e.g. ^A\) might be valid, but they're not attribute
control codes, so their existence would cause this function to return true.

There are still places where it could be logged in <> (if username is not yet
known).

Add JS console.ansi_getdims()

Use sbbs_t::getdimensions() or JS console.getdimensions() to move user
cols/rows values to run-time console values (querying ANSI terminal if
appropriate/supported).

JS console.pushxy(), popxy(), and gotoxy() all return Boolean now.

sbbs_t::getdimensions() and its JS wrapper is now the proper way to propagate
user's cols/rows settings to the run-time console values. This was done
(post-login) only via use of the TERMROWS and TERMCOLS @-codes in
user_settings.js. Weird.

receive_thread() needs to use the control session correctly for
TLS connections.

Ideally, a sysop would never need to disable FTPS support, but as a trouble
shooting measure, it can be helpful.

to node.log via sbbs_t::log()

Some doors/door kits actually require all 52 lines, but since they
(may) have problems with the values we populate on those additional
21 lines, just write them as blank when a program is configured for
the GAP (original) 31 line DOOR.SYS drop file. I doubt (and hope)
that no programs will care if their are more lines than they expect.

So apparently 23 years ago (almost 24), I made a typo in commit
7731d16d that broke the batch transfer menu for RIP users.

Also elminated silly/unnecessary loop-control variable ('done').

I'm working on a port to JS and noticed these oddities (so far).

Removed UTIDOOR.TXT file format: nobody uses this drop file format and we
removed the UTI driver long ago, so this was just an artifact.

If you previously had an external program (door) configured in SCFG to use
the "GAP DOOR.SYS" file format, SBBS will create the same (52 line) format
as before (no change).

But for doors that have compatibilty issues with the 52-line DOOR.SYS file
created by Synchronet (e.g. Thunder cat V3.30), a sysop can now choose "GAP
(original)" for the drop file type and Synchronet will create a 31-line
DOOR.SYS file instead.

Not sure how I missed this one, but this file was needed to complete the
'bbs' object changes mentioned in that commit message.