Unlikely, but valid thread-safety concerns by Coverity

In response to Nelgin's inquiry:
DigitalMan would it be difficult to add login/logoff date/time to these
messages?
Node  2: xxuserxx logged on Telnet
Node  2: xxuserxx  logged off

Now, you can just use @-codes to add that kind of thing to these text.dat
strings.

Ideally, this would use startup.tls_error_level, but which one? And how?

Also, make a TODO comment to fix the fact that all JS Socket log messages
are logged to the terminal server log output. :-(

Saves some opening, reading, and logging, but otherwise was harmeless.

Fix issue #422

Seriously though, this doesn't always do the same thing as outputting a '\n'
(e.g. in PETSCII mode, it sends a "cursor down" (17) control character).

Also use sbbs_t::newline() as the underlying implementation of
console.newline() rather than a hard-coded CR/LF output loop.

Added new console methods:
	cond_newline() - equivalent of Ctrl-A/
	cond_blankline() - equivlaent of Ctrl-A?
	cond_contline() - equivalent of Ctrl-A\

... so a JS script author doesn't have to output Ctrl-A codes to invoke those
functions.

To enable a server that's disabled in the sbbs.ini file, just use the <server>+
option (e.g. 't+' to enable the terminal server). To run *only* that server
(and no other servers), use the '<server>!' option (e.g. 'w!' to run *only* the
web server).

js_init() failures are now logged with a critical error level (instead of just
"error").

js_execxtrn() now returns -1 if a JS context can't be created. This eliminates
redundant error messages from calling js_execfile with a NULL context.

Replaced _property_ver_list (array of numbers) with _property_ver_list (array
of objects) with a "ver" and (optional) "desc" property. This solves the
enumeration order problem with objects that have both manual and table-based
properties. Object's property tables (arrays of jsSyncPropertySpec) can now
(optionally) contain the property descriptions. For properties defined in this
manner, there will never be another mismatch between ther name/type and
description/version in the jsobjs.html (a problem has re-occurred several
times through the years with nebulous work-arounds).

We still use _property_desc_list arrays for additional (e.g. manually defined)
properties in such objects or just objects that only use one method of
property definition and are not subject to the enumeration order problem.

Fixed numerous typos.

Using more consistent terminology and HTML mark-up.

Some beautification and enhancement of readability, but nothing too major.

We don't need the carriage returns and they cause Git warnings:
warning: in the working copy of 'src/sbbs3/text.h', CRLF will be replaced by LF the next time Git touches it

Fixes issue #670

New method: bbs.load_user_text() to load/reload user's language file. The
user's select language file (if there is one) is automatically loaded upon
logon to the terminal server, but if the user changes their language
(e.g. via user_settings.js), we needed a way to force re-load of the language
text. This is the way.

bbs.text() now accepts an optional second (bool) argument that if true, will
return a string from the default language strings (in text.dat), and not a
string from any alternate language files (ctrl/text.*.ini) that might've been
loaded. This allows user_settings.js to always get the name of the default
language string (LANG), e.g. "English".

The CTX constructor arguments weren't documented

Some blind beautification via HTML tags

Also clarify (or try to clarify) that the maxlen argument is required if you
want to specify any kmode flags.

Ragnarok (DOCKSUD) would like to use lang_COUNTRY for their language files
as  "I use es_AR and is exactly not same to es_ES"

It's trivial to extend the length more if there's a desire to do that.
That's a nice thing about the new (in v3.20) user.tab file format.

C++ Builder6 doesn't have unordered_map, so only #include those std C++
headers if/where we actually need them.

Whoohoo, I'm a reel STL programmerz n0w!

error: ISO C++ forbids comparison between pointer and integer

Uses the new ctrl/text.??.ini files (just a few words translated so far).
Adds the new "lang" user property (to user.tab and JS User class).
The language code is the 2-3 char (e.g. ISO 639-1) abbreviation of a language.
A "blank" language property value (the default), just means to use the
ctrl/text.dat contents.
User-selected alternate language file is loaded upon logon and in the
built-in/hard-coded user default settings menu.
More on the user default settings menu:
- AutoLogin via IP option ('I') to make room for new (I) Language option.
- The cold-keys menu option was removed to make room for Language option
  (via text.dat change to UserDefaultsHotKey)
- Any options disabled via blank text.dat strings will no longer result in
  supported command keys (that could accidentally be struck with hidden
  consequences/effect)
- The user_settings.js will need similar treatment

text/menu/<lang>/* is where alternate language menu files should be stored

New UserDefaultsLanguage text.dat string (inserted before new PasswordChar
string).

This fixes the issue with the ContinueQ setting in ctrl/text.??.ini when
attempting to use one of them to replace text.dat strings with localized text.

In a fresh install, neither of these files would exist, and that's normal,
so getstats() should just return true in that case (with the stats struct
zeroed-out).

Fixes error during login to a new install reported by Zoltán Gábor on
Facebook.

... in the linked node listing

Running SBBSCTRL on Windows 11 with a 4K monitor looked horrible.
The default font sizes varied widely - I'm not sure why this wasn't
apparent before now. And the default font ("MS Sans Serif") is no longer
included in modern Windows versions, so when choosing a Log font, the
pre-selected font was just blank. So change use of "MS Sans Serif"
everywhere to "Microsoft Sans Serif" which appears to have been around since
Win95 and be the preferred alternative. I would consider Segoe, but that
wasn't introduced into Windows until Vista and I'm not sure (yet) what
troubles that might introduce. I'll experiment with a WinXP VM maybe
and find out.

Also:
For log message styles (e.g. colorization) based on log level, don't apply
a different font (Name) or size. This just looks terrible when this is done
and I don't think any sysops want that. Keep each log window using the same
font face (name) and size, just allow the color and style (e.g. bold, italics)
to change based on log severity.

This does increase the confusion with the Properties->Customize->Log Fonts
as the "Change Font" dialog still allows the sysop to select/change a font
face and size, they're just not saved/used. I coudln't find a way to remove
or disable these from the displayed TFontDialog form.

Win32 GDI mode is also native, so let's be more specific.

Apparently this was non-intuitive to sysops. <shrug>