uncrustify nl_split_if_one_liner setting

... using uncrustify mod_paren_on_return config

White-space changes only, exception being the rare insertion of NL before
closing brace (couldn't find the option to disable that behavior).

I excluded some header files (e.g. sbbs.h) since uncrustify seemed to be doing
more harm than good there. I might just end up applying different set of rules
to .h files.

... since these methods only feed the keyboard buffer.

Add an optional 'insert' argument to console.ungetkeys() - default is false
(append).

Add a new version of console.ungetstr() which feeds the passed characters
directly to the receive input buffer. Now returns bool indicating success.
Existing scripts (if any) that use console.ungetstr() should continue to work
just fine.

This is anticipation of telgate.js being able to stuff strings (e.g. username,
password) into the input buffer and those chars/keys being passed to the
remote (gatewayed) telnet server. Since the telnet gateway reads directly from
the receive input buffer (ignoring the keyboard buffer), we needed a way to
stuff strings of characters into the receive input buffer directly and that
sort of exposed the weirdness of the existing console.ungetstr() method:
- it didn't return a return value (not indication of failure)
- it didn't support an 'insert' operation (even though the underlying C++
  method does)
- it didn't use the sbbs_t method that already existed for feedding a string
  of characters into the input/keyboard buffer

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.

This is for sysops that never want mouse hot-spots in their BBS menus and
prompts (e.g. Kirkman, possibly Deuce) - set to "No".

Setting to "No" also disables the function of the JS console.add_hotspot()
method. Perhaps it should not. <shrug>

Setting to "No" does not disable the terminal mouse support question when
users are setting their terminal defaults. Perhaps it should.

This option should default to enabled (sysops that depend on mouse hot-spots
should double check) - it's enabled in new/stock installs.

K_CP437 changed to K_UTF8 with the inverted logic. If you have code/script
that can handle UTF-8 input, then you need to specify K_UTF8 in calls to
inkey, getkey, getstr. Or else, you're going to get a CP437 translated
version of any non-ASCII (UNICODE) UTF-8 chars, if there's a mapping
available. This only impacts UTF-8 terminals.

There are just so many places in Synchronet where UTF-8 input could cause
problems, it makes sense to translate UTF-8 to CP437 by default and make
true UNICODE/UTF-8 handling the exception.

Sorry Nightfox, you'll need to remove the K_CP437 detection/use code you
just added to SlyEdit.

If you're writing, say, a message editor and you don't want to deal with
UTF-8 input at all, specify this mode flag to convert any translatable UTF-8
chars (that have CP437 equivalents) to CP437 chars. Non-translatable UTF-8
chars are just ignored (treated the same as a timeout/no-input).

There are other ways to generate forced-upper case expanded @-codes, if that's
what you want.

Fewer duplicates in text.dat make localization, translation to other languages
easier.

Adding and removing typecasts and changing some types (of ints).

So Clang-FreeBSD was warning (in compiles of scfg/scfg*.c by Deuce):
result of comparison of constant 100000 with expression of type 'uint16_t'
(aka 'unsigned short') is always true

Why? Cause a uint16_t's max value is 65535 (less than 100000). Sure we could
have just lowered the UIFC max number of config items to 65535, but that would
have been too easy. And why are these compared-with values of type uint16_t to
begin with? Because most ctrl/*.cnf lists (of configuration items) were
limited to 65535 entries cause ... 16-bit DOS, historically. Now that *.cnf
files aren't used, we could just increase these scfg_t.*_total type sizes from
16 to 32-bits, yeah? The result is this commit.

I went to (signed) int so we could still keep -1 as the special illegal
sub/dir num value (e.g. INVALID_SUB, which is sometimes used to indicate the
email message base). Theoretically, 2 billion configuration items could be
supported in these lists, but SCFG will limit you to 100000 anyway. So there's
a whole lot of s/uint/int in this commit.

I'd be very surprised if this doesn't result in some new GCC/Clang warnings,
but at least the old "comparison of constant 100000" warnings are now gone!

My first idea was to have a per-external-program setting to enable input
translation, but Deuce suggested it would be better done in input_thread() and
after some thought, I agree. Translations are not done in data/file transfer
mode, so use the CON_RAW_IN console flag to indicate this condition. So even
JS console.getbyte() will return a translated char unless the console is set
raw input mode (this could be surprising behavior for some!).

I considered saving/restoring the console mode when performing a file transfer
but will leave that to a time when obviously needed.

This fixes issue #497 in automatic way (no option needed).

- New keys in [BBS] section of sbbs.ini:
  MaxLoginInactivity (default: 10 minutes)
  MaxNewUserInactivity (default: 60 minutes)
  MaxSessionInactivity (default: none/unlimited)
- Each configured external program/door in SCFG can have its own maximum inactivity setting (or else the session max inactivity is applied)
- moved node-specific sec_hangup to system-wide/shared max_getkey_inactivity (configured in SCFG->System->Advanced)
- moved node-specific sec_warn (seconds of inactivity before sending warning) to inactivity_warn (a percentage of elapsed max inactivity before sending warning), also configured in SCFG->System->Advanced and used for both socket and getkey inactivity detection
- Renamed JS console.inactivity_hangup to console.max_getkey_inactivity (old name remains as alias)
- Renamed JS console.timeout to console.last_getkey_activity (old name remains as alias)
- Removed JS console.inactivity_warning
- Added JS console.max_socket_inactivity (current input_thread inactivity threshold)
- New text.dat string: InactivityAlert (just contains 3 ^G/BELLs by default) used for non-visual inactive-user warning

The MaxLoginInactivity setting in particular solves the problem of custom scripts (e.g. animated pause prompts) that just poll indefinitely for user input and never time-out  - these will no longer cause nodes to be tied-up with inactive/bot users at login.

You may ask yourself, how did I get here? No, you may ask yourself: why configure these socket inactivity max values in sbbs.ini? The reason is consistency: sbbs.ini is where the MaxInactivity is configured for all the other TCP servers and services.

This fixes issue #534 for Krueger in #synchronet

That's all these macros were doing anyway, so no change.

Does exactly the same thing, no change in behavior and unlikely there's any change in performance.

Mostly [s]printf format fixups

At one time, Synchronet was a 16-bit DOS project, plagued by the 16-bit [u]int, so long's were used everywhere > 16-bits were known to be needed/wanted (This is before the days of the standard sized types from stdint.h), and they've persisted.

But '[u]long int' is 64-bits on *nix 64-bit builds, 32-bits everywhere else (even 64-bit Windows builds if/when we ever get around to that), so this could lead to insidious bugs that would only show up on one flavor or the other. Since [u]int is 32-bits on everything we currently support, we'll use that instead of [u]long.

This "part 1" because I'm sure there's going to be warnings and errors from the GCC/Clang builds as a result, which I'll get to next.

Move kbincom() to an sbbs_t method.

No functional change here, just getting ready to support input translation for stdio
external programs as an option.

This was a bug if the user had set their terminal to swap Delete and Backspace keys while not using a PETSCII terminal.

A single source of truth is now used for SBBS's mouse mode (MOUSE_MODE_ON). A JS script doesn't need to know what SBBS's preferred/default mouse-enabled mode flags are, just set to this property to "true". Setting to "false" is the same as setting to MOUSE_MODE_OFF (0).

As described in issue #412, when using extended mouse coordinate (SGR) mode, the mouse button release sequence would be received by the BBS after the hotspot-activated menu option was executed and then that button release sequence possibly passed through to the a child script or program that didn't know how to handle or ignore it.

To resolve this, the BBS now ignores ("eats") the mouse button *press* sequence and only acts upon the mouse button *release* sequence. This is more aligned with how button-clicks work in mouse-control/GUI applications anyway.

In the mouse debug log output. Potentially helpful in debugging mouse related issues when using the SGR mouse reporting mode.

This eliminates some link-list management and the debug-level log message "Scrolled x mouse hot-spots" for non-mouse-enabled user terminals.

... even in debug builds (was already disabled for release builds)

I haven't played with this chat pager in *years*! The lowest tones were inaudible (raise the range from 0-800Hz to 400-1200Hz).
Increase the msgabort() tone from 1 to 10ms, sounds like those computerized voice recognition phone systems now.

Remove the redundant "<user> paged you to chat" notifications (and log message) when turning *off* the chat pager.

Some terminals can send NUL (ASCII 0), e.g. hitting Ctrl-Space in Apple iTerm. Allow users of inkey() (in C++ or JS) to optionally detect the difference by specifying the K_NUL mode flag. In JS, console.inkey() will return null upon timeout (rather than "") when the K_NUL mode flag is used and return an empty string ("") upon receipt of NUL (ASCII 0).

The default is the previous behavior where a timeout and the receipt of a NUL character appear the same to the caller of inkey().

In preparation for node-spy applications that can support multiple terminal sizes/types (none exist yet). The file is updated whenever there is new/updated information about the client's terminal.

Exposed as JS method: console.term_updated().

I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.

This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).

The new macros names are bit more descriptive as well.

The reported problem (by John "Jay" Crutti) was:
If autodetection of the terminal is used from the defaults menu I get stuck on the prompt to hit my Delete key because on the BBS, it keeps showing me login statistics every time I hit my delete key. 

Add/use new K_CTRLKEYS mode to stop inkey() from handling/eating control-keys (e.g. Ctrl-T) when asking user to hit backspace during defaults->terminal settings.

Allow PETSCII_DELETE (Ctrl-T) as a valid option when asking for the backspace/delete key and set the PETSCII flag in the autoterm variable if hit by the user.

The default terminal columns (still 0/auto) can be overridden with the 'L' command from the user defaults menu. 

Also increased maximum manual terminal rows setting from 99 to 999 - this involved moving the record in user.dat, though the old record value is auto-migrated.

As reported by Ragnarok and The Lizard Master, invoking a JS global
hot-key handler (e.g. hitting Ctrl-U or Ctrl-P with the privatemsg
or nodelist modules installed as handlers) would lead to the global
object being cleared/corrupted so other scripts would then fail to
run correctly (e.g. Error: can't open sbbsdefs.js: No such file or directory)

This probably explains the JS_GC/JS_ENDREQUEST change needed when
the hotkey-specific JS runtime/context/scope was introduced last year.
Should revisit that too.

Allow set_mouse() to disable mouse-reporting in the terminal (if it was previously enabled), even when mouse support has been turned off by the user.

so made it enabled/disabled per-user-terminal settings. This means that if
you were already enjoying mouse support, you're going to have to turn it on
to keep enjoying it. It also means there's currently no way to enable/use
mouse support pre-logon, but I have ideas about how to support that for
sysops that want that.

Rename CON_MOUSE_REPORT to CON_MOUSE_SCROLL (since that is all it is used for).

Support mouse scroll-wheel mapping to up/down arrow keys by setting CON_MOUSE_REPORT flag in sbbs_t::console (JS console.status).
This also means that the mouse hot-spot support now uses XTerm "normal tracking mode", so mouse button releases are also reported by the terminal (and eaten by inkey(), when CON_MOUSE_PASSTHRU is not enabled).

Support a "mouse pass-through" console status flag to allow the pass-through of uncaptured mouse reports (e.g. for hot-spots) to other tasks/scripts. When there are no active hot-spots, this is the normal behavior.
This commit leaves the legacy X10 mouse report handling/pass-through logic in. But I'll likely be removing that soon.

Now that pause() can set a hot-spot, don't inject a Ctrl-C (abort) into the keyboard buffer if it had.

The 3rd step of the hungry hot-spot matching algo now looks for the left-most possible match in reverse creation order. This solves the problem with clicking left of "Yes" in a yes/no prompt registering as a "No'.