Don't corrupt UTF-8 strings with SAFECOPY() (use new SAFECOPY_UTF8).

Some terminals (notably, Windows Terminal) display zero width UNICODE chars
as a single column-wide space. <sigh> Auto-detect the zero-width "width"
(1 or 0) of the terminal during connection and UTF-8 auto-detection.

getstr() works a lot better now with UTF-8 strings with wide chars (e.g.
emojis), but likely much more to do.

This is not a completely unexpected thing to happen during ungraceful
termination

I'm surprised this didn't create a warning somewhere: treating char* as a
bool!

Which means that every time textgen was built, it was immediately out of
date (and requiring a rebuild).

(doesn't leave a partial UTF-8 sequence at the end of the destination string).

This calls memcpy() for every char, which may not be performant, but I didn't
(yet) do any profiling. Hence, no premature optimization either.

Tested with Windows Terminal Version: 1.18.10301.0 and all codepoints between
0x100 and 0x1FFFF, this change reduces the width mismatches from > 8000 to
349. The "Zero width" mismatches are probably the most important/glaring and
will need to be addressed next (since some terminals don't move the cursor
for zero width chars, and some do).

(but prefer the proper/configured case, based on config in SCFG).

Works around a problem where DDMsgReader always creates QUOTES.TXT (never
quotes.txt), but SBBS tries to read in the file with the case it expects.
This wouldn't be a problem on case-insensitive file systems (Windows).

Resolves the writemsg.cpp error reported by Nelgin

ubiquitous now (except for Borland of course, which doesn't count)

long long when compiled with MSVC.  Re-enable it.

Apparently, fiddling with them in there "strongly implies" to Coverity
that vstatlock needs to be held to access them, and it's good form
to have the lock held for the least span possible.

Found by Coverity.
If there's actually another thread using the list when the refcount
hits zero, you're going to have a bad time regardless of the lock.

Coverity has been pointing this out for a while, but we've been
ignoring it as a false positive.

Commit 75c5c9e5 was initially to address server termination (sisue #236), but
expanded in scope to include server recycling (e.g. due to semaphore/config
file touch) and that turns out to not be what most sysops want.

If you want an immediate/ungraceful recycle, do a restart (shutdown/stop and
then start) instead.

Immediate/ungraceful server shutdown/termination is still in effect however.

No change to the "server pause" feature either, so combining pause with
recycle would be effective to prevent *new* client connections while waiting
for existing clients to disconnect and allow a recycle to happen.

Commit d1182efc

(or terminating) the server.

This will allow background JS threads to terminate when recycling, so the
server doesn't just hang indefinitelyi when recycling.

Add more logging in cleanup() when waiting for children threads to terminate.

Also, eliminate the global 'terminate' variable, answering the question:
  Can this be changed to a if(ws_set!=NULL) check instead?

Yes, yes it can.

e.g. month and day reversed

Updated help text for "Support UTF-8 Encoding" for external editors.

1. Add an 8th line to MSGINF (for SlyEdit): the character set expected
   (either "CP437", the default, or "UTF-8") based on the SCFG configuration
2. Don't apply "Soft-CR" (0x8D) stripping/expansion for UTF-8 editors

*This* is the way. Oops.

This is the way.

This was the auto/default mode before commit 2ca1e4a0

If you really want the VGA aspect ratio, use the '-v41' option.

dirty = true propogates up, dirty = false propogates down.

Since we're modifying cryptlib anyway, we can't just dlopen any old
cryptlib library.  Require linking with the lib.  This will break
the MSVC build, so disable that for now.

than err_len containing garbage.

Handle the error and mention we didn't get the message.
While we're here, check the return value of malloc().

Given how patched up cryptlib is at this point, this is all likely
to go away and just use the static lib in the nearish future.

If call to GetAttributeString() fails, err_len can contain garbage.