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.

e.g. [can|is]_subject_something() is now named subject_[can|is]_something()

No functional change.

Addresses Clang warnings about deprecation

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!

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.

Upload and Download ARS must be matched *and* the directory's upload and download ARS.

Operator and Exemption ARS must be matched *or* the directory's operator and exemption ARS.

Since users can (and usually do) display extended descriptions in their normal file listings anyway, it makes sense to go ahead and search them for the text (e.g. with the 'F' command from the default command shell File menu/prompt). So the "search/display extended info" prompt has been changed to just "Display extended file info" since it no longer controls whether or not the extended description is searched for the text (it always is). The FL_EXFIND was renamed to FL_EXT and only controls whether the extended info is display (the FL_FIND mode flag, always renamed, must also be specified for a find with extended info).

This closes feature request #285 by Phil (@plt).

I forget who it was that said they were still using this feature in v3.18, but here you go, it's working again (the /D and /U commands). I'm not migrating any file sender/recipient info from v3.18, so only files added after upgrading to this will be downloadable from the "user" directory (if you have one).

Something that I never implemented before but noticed is missing is the removal (or dereferencing) of user-to-user files that were sent from/to a user that is then deleted. So that's still a TODO item.

This won't impact Synchronet as it has a separate signal handling
thread, but we still need to behave properly for processes that
don't.  I'm also saying that ENOMEM does not indicate a disconnection,
though it may be better to pretend it was disconnected...

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.

- User Defaults menu mousified
- When all hot spots have scrolled off the screen, clear the hot spot list
- Insert new hot spots in the front of the list so they will take precedence
  over any previously defined duplicate hot spots
- Numeric hot spot commands end in a carriage-return
- No auto-acceptence of numbers when there are keys in the keyboard buffer
- Baja UNGETKEY function now inserts keys into the "front" of the keyboard
  buffer (next to be consumed)
- Hot key @-code command text supports C-style escape sequences
  (allows encoding of ctrl chars, spaces, etc.)

some times.

menu() if it does (exist) and doing something else if it doesn't.

- if the sysop had text/menu/<filename>.bak (for example), the optoinal menu
  would attempt to load, resulting in an error ("<filename>.asc not found")
- if the sysop specified menu_file or menu_dir (e.g. via Baja), the existing
  checks for optional menu file existance would not work

of configured upload requirements) and exceed the "max files" settings per dir.
Also, directory operators now always have upload permissions.

That is, if any of the following text.dat entries are set to a blank/emtpy
string (by editing ctrl/text.dat or via run-time script modification), the
question will not be asked of the user allowing greater sysop-customization
of hard-coded processes (e.g. new user application):
ClearUploadQueueQ
ClearDownloadQueueQ
HangUpAfterXferQ
ChatWithGuruInsteadQ
ForwardMailQ
DownloadBatchQ
LogOffQ
DeleteErrorLogQ
ClearErrCounter
DeleteGuruLogQ
AutoTerminalQ
AnsiTerminalQ
ColorTerminalQ
ExAsciiTerminalQ
CallingFromNorthAmericaQ
ReadYourMailNowQ
NScanAllGrpsQ
SScanAllGrpsQ
NewPasswordQ
ContinueQ
EnterYourPhoneNumber
UserInfoCorrectQ
UseExternalEditorQ
DownloadAttachedFileQ
AddSubToNewScanQ (new)
RemoveFromNewScanQ
DisplaySubjectsOnlyQ
Post
SearchExtendedQ
ViewSysInfoFileQ
ViewLogonMsgQ
WithLineNumbersQ

Added HOST and IP keywords to allow restricted access/privileges to/for
specific remote hostnames or IP addresses (wildcards allowed).
All string-argument type ARS keywords (e.g. SHELL, PROT, etc.) now support .can
style wildcards.
The current remote client is now used for protocol, host, and IP ARS checking,
when available, so this requires passing the client pointer around (which
explains why so many files are touched by this change) and takes care of a
long standing to-do item (the user's 'modem' value was used for the PROT
value checking, which was not always correct).

file databases.

(no longer members of the C++ class sbbs_t).