The last commit changed the environment, so we need to regenerate
the config cache.

The big remaining issue is defining *_EXPORTS where needed, which
looks rough from a quick glance.

There's only one toggle left (Leave node file open) and not very many advanced
options.

Unfortuantely, can't easily do the cool left-right cycle through nodes since
each node file has to be saved/loaded, but still, easier to visualize any
differences between node configs with all the settings on one menu.

From SCFG->Nodes ... Toggle Options to SCFG->System->Toggle Options

And from a bit flag in node_misc to its own bool member of scfg_t.

The way this option worked was, if enabled (and it was off by default), bit 7
of all character input *before* successful logon would be stripped and bit 7
from all character input of terminals configured as US-ASCII (only) would be
stripped after logon.

Instead, always strip bit 7 (the 8th bit) of each input character from US-ASCII
(only) terminals. Other detected/configured terminals (CP437, UTF-8, PETSCII)
won't have bit 7 stripped (ever) since that's likely not a necessary or nice
thing to do. There's now no different handling of pre/post logon in this
regard.

If there's a need to strip parity bits from character input from client
terminals that support CP437, UTF-8, or PETSCII, then we'll re-add this feature
in but it shouldn't be a per-node setting in that case.

The configure script was using uname -m as the build platform, but
Bullseye on RPi uses a 64-bit kernel (aarch64 uname -m) with a 32-bit
userland (arm gcc build host), which resulted in a lot of bad decsions
around JIT stuff.

With this change, we explicitly pass the build/host/target values as
taken from the compilers in question, which fixes the issue for Bullseye
(But may break mingw32?  Well we'll see how the pipes go).

4-bytes is how bit a 32-bit pointer is.

This works on Buster at least... update the other config.guess file
the same as the top-level one, and always define JaegerSpew() so the
JIT stuff isn't broken.

Yeah, it's getting about that time...

Addresses issue reported by Dumas Walker (CAPCITY2) and kk4qbn (KK4QBN)
whereby the list contains filenames in the wrong case.

As I said, untested.

Passing an unparseable integer to console.editfile() could leak heap memory

A couple of error paths in expand_atcodes() method could leak heap memory.

This should resolve CID 487088: Unchecked return value from library
as well as add some more instrumentation upon unexpected failures removing
files.

Consider: do some callers of this function need to know the success status
(return bool)? That then starts to get into the some callers check and some
don't situation (Coverity issue). For now, this is a void function.

Also, all remove failures are logged as errors. Consider possibly passing
a log level and calling lprintf() instead of errormsg(). errormsg() displays
a notice to the user, which maybe we don't want.

Ideally, I'd use atomic_bool instead, but we're using an older WinSDK for Win7
compatibility and so... can't.

Perhaps an xpdev 'protected_bool_t' should be created.

gmtime_r() can return NULL

Resoles (at least) CID 488305

... so use strncpy() and TERMINATE() here (instead of SAFECOPY) to resolve
newly reported Coverity issues.

There may be other places where we're using SAFECOPY() with an unterminated
source string that would've been fine before we switched SAFECOPY from using
strncpy to strlcpy. So we should reconsider that change.

The ppm (image) of course is 24bpp, and the pbm (mask) is 1bpp, so
the line lengths are different.

No functional change

Both sbbs-noskeeters and sbbs-build create sbbs-build.tgz
Hopefully this fixes it and doesn't just break it worser.

Reverts gen_defs/genwrap craziness.

This whole library is starting to get crufty and could use a room
at a hackathon.

This should hopefully surface whatever is corrupting the file.

C++ <sigh>

We don't need a .ini section separator anyway.