DDMsgReader: Quick-validation of local user (Ctrl-Q) - For issue #548

Closes #548

See merge request !285

When adding a BBS entry with a TCP connection, if a ":port" suffix is included
(e.g. "vert.synchro.net:23"), parse and use that port number for the new entry
automatically and remove the suffix from the adddress itself.
This is just a time saver when adding new BBS entries.

Care was taken to not treat the following addresses in this manner:
 ":<port>"   - would have resulted in a blank address
 "a::<port>" - possible IPv6 address
 "a:<port>b" - possible IPv6 address or ... ?
 "a:<invalid-port>"

DD area choosers: Bug fix for current selected sub-board/file directory when using collapsing. Color settings no longer need the control character.

See merge request !284

When Secure EchoMail is enabled and a Bad Echo Area (*) is defined in the
area file (areas.bbs), but the packet source address is *not* listed as a
link to the Bad Echo Area (tag: *) in areas.bbs, any messages for unknown
areas in such a packet would cause the pkt to be considered a bad packet
with a security violation. Instead, the message should just be skipped.

Set the CIOLIB window title (so it's not the default "SyncConsole")

DD area choosers: Bug fix for current selected sub-board/file directory when using collapsing. Color settings no longer need the control character.

So a sysop now has 3 choices for SBBSecho's handling of incoming bad packets:
 - delete them
 - rename them *.bad
 - rename them *.reason.bad (the default)

If SBBSecho is configured to rename bad packets, but the rename fails, the
error is logged (as before) but the packet is not deleted (this is a change
from previous behavior).

Always log the *reason* a pkt was determined bad in the "Bad packet detected"
log message.

When bad packets are detected and renamed to ".bad" files, include the reason
in the new filename (e.g. "ff69453a.src-addr.bad" or "ff69453a.pkt-passwd.bad"
instead of just "ff69453a.bad") to make it easier for a sysop to determine
what to do with the bad packets without having to search through log files
to discover the reason *why* SBBSecho considered the packet to be bad.
This behavior can be disabled if desired by setting EchoCfg->Global->Verbose
Bad Packet Names to "No". Note: the reason used is the *last* reason
detected/logged for a packet to be considered bad; it's possible that there
are multiple reasons that a packet may be considered bad. All reasons will be
logged, but only the last reason is used in the new bad packet filename.

Also added the missing "Delete Packets" option (to EchoCfg->Global). Though
this setting was added in sbbsecho v3.0 (and settable via sbbsecho.ini), it
was never exposed via EchoCfg; I don't think that was intentional. Normally,
you'd always want to leave this set to Yes (the default) to delete processed
packets, but when debugging, it may be desirable to leave the packet files
in place. This what the old sbbbsecho v2 '-x' command-line option used to be
used for (disable the deleting of processed packets).

Moved the Global Settings, EchoMail Settings, and File Paths config menus to
the upper left of the screen in EchoCfg. The placement seemed inconsistent
and erratic, so this is a bit of a cosmetic improvement.

Using the same logic that SBBSecho uses to decide if a packet header is in
fact 2+ (the auxNet field must be non-zero), otherwise, type reported is 2e.

CID 452331
CID 452330

The CP437 character characters used for the arrow indicators aren't always
mapped to the expected characters in all fonts (e.g. on Windows), so add an
option to use ASCII alternatives (<>^v) when that's a problem.

Command-line options must begin with '-' (not ye olde CPM/DOS '/option')
Command-line options are now all case sensitive (e.g. '-a' not '-A').

Remove '-d' (long deprecated for '-id')
Remove '-t' (long deprecated, do nothing)

I noticed when setting a security level's lines per message value > 32767
in SCFG->System->Security Level Values, the value would be read back as 1 or
or some other crazy value. That was because we were writing this value
(and all the security level 16-bit values) using iniSetShortInt(). These are
*unsigned* 16-bit values, so that we should have been using iniSetUShortInt().
We'll just use iniSetUInteger() instead to fix that/those issues.

And since promotion/conversion from uint16_t or uint32_t to uint has no impact
when creating a decimal representation of a number, just use iniSetUInteger()
everywhere we're setting unsigned integer settings in the main config .ini
files. If/when these fields are made larger in the future, this code will just
work.

When reading .ini integers, use the more appropriate iniGet[U]Int16 functions
instead of iniGet[U]Short and use iniGetUInteger for reading enums or any
values that are immediately typecast to a uchar/uint8_t.

Replaced some other use of [u]short that I found when searching with stdint.h
types.

Rather than recomputing (possibly differently) the max lines in multiple
places.

This also enables the possibility that editfile() could be used to edit files
of > 10K lines in the future. <shrug>

If a user's security level lines per message was set to '0', bad things would
happen to the heap if the user posted/sent a message. '1' is a reasonable
minimum value. If you don't want a user/group of users to send/post messages,
there are restrictions for achieving that. Also this setting is (currently,
at least) 16-bit, so clamp it there too on the high end.

Also clamp the expire-to security level setting between 0 and 99, while we're
here and noticed that this value wasn't being sanitized either.

If the top already ends in a blank line, no additional CRLF is warranted
(between the 'top' and the raw-input message 'body').

Replace the suspicious strcpy/strcat's in msgeditor(), the built-in line
editor, with bounds-enforced snprintf() calls.
Also, properly define MAX_LINE_LEN to account for the trailing \r\n on each
line. It appears we've been under allocating the total possible message buffer
size (by 2 bytes per line) for a while now.
These 2 changes together should fix issue #547: apparent heap corruption due
to 'buf' overflow in msgeditor().
Also added a line count check/cap-enforcement with logged error message if
exceeded (should never happen).

Also fixed in this commit: off-by-one when enforcing max message length in
msgeditor().

Also added checks that the 'cols' (used in MAX_LINE_LEN) are reasonable values
(40+), 2 was below the threshold of what would be expected to work since
there is logic that deducts 4 from cols, for example.

This bug only impacted non-passive FTP connections. Using an FTP client
with active (not passive) data connections over an IPv6 connection would
false-trigger the "bounce attack" detection and the FTP server responded with
"504 Bad port number" and logged a hack attempt in data/hack.log.

The issue was that we were comparing the socket address structure (which
contains other fields besides the address itself) between the control and
proposed-data connections. While this logic worked okay for IPv4,
it did not for IPv6 (the 2 structs contained some non-address differences).
Rather than modify the socket address structures to match where needed, I'm
just comparing the string representation of the addresses, since that's
what we really care about anyway.

Thank to "mark i" of Truck Stop BBS for alerting me to this issue

Sometimes F1 doesn't work, Ctrl-Z isn't documented, but there is a '?' displayed
when help is available, so it's reasonable to assume someone might try/use it.

For Dasme.

Minor beautifications

Initial commit for The Outhouse IGM.

See merge request !283

DDMsgReader: Check console.aborted instead of ctrl-C keypress for aborting searching and scanning

See merge request main/sbbs!282

This lowercase's the entire path.

Fixes issue #543

The sbbs_t::wordwrap[] buffer was 81 characters (80 printable characters, plus
NUL terminator) and sbbs_t.getstr(), when used with the K_WRAP mode flag could
potentially write more than 81 characters to this buffer (e.g. when using a
wider than 80 column terminal and writing a message with the internal line
editor which calls sbbs_t::getstr(... K_WRAP)) - would corrupt sbbs_t members
after wordwrap[], which included pointers that would be freed in the sbbs_t
destructor (~sbbs_t) and subsequently page/segfault as seen in issue #545.

This change increases the wordwrap buffer to likely twice the same needed
(maximum columns + NUL terminator) and adds wordwrap bounds checking to
sbbs_t::getstr().

There were comments indicating crash sightings in the sbsb_t destructor going
back to 2002, so this commit removes those comments.

Thanks to Nelgin for providing the gdb dump details ('print *this') that was
the clue needed to reach the root-cause determination.

This fixes issue #545.

Useful when debugging mail issues, e.g. with MIME-encoded mail

Fixes issue #544

Need to use this for creating nightly sbbs_src.tgz file

Also suppress the diff errors when the git_*.h files don't exist

DDMsgReader: Ctrl-C is now supported for message searches to abort the search.

See merge request main/sbbs!281