[s]printf format fix-ups

Likely a part 4 coming next after building with GCC.

And other potential occurrences of this when not in a channel

Be consistent with the other action/* topics.

The format string used did not insure there was any space between fields leading to very hard to parse stats, like this:
User          2  SSH      12:25 12:39  14554  0  0  0  0  0

That's 554 msgs read in 14 minutes online, but well, you see what I'm say'n.

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.

modem init strings, alt file paths, PostLink name/number, node-specific command-lines, etc., many of these haven't been used since SBBS v2.

Also, use easier to read byte value strings in email and log msgs.

With this commmit, the logic is now:

If the NetMail destination is a point and there's no linked-node for it
   and the boss node for this point is not one of our AKAs
   then route to the boss node (no linked-node match needed)
   if the boss node matches a linked-node with a route configuration
   then route to that configured route destination (2-levels of routing
   and thus 2 "Routing NetMail" msgs will be logged in this scenario)

If the NetMail destination is a point and there is a linked-node for it
   then the netmail will not be routed
		unless that linked node has a route configuration

NetMail destined for non-points are treated the same as before this
commit.

No change in the routing of echomail for points.

I think this change fixes issue #520 which can be traced back to commit
7bd42e56 for poindexter FORTRAN (REALITY), 2 years ago almost to the
day, where that change added point->boss routing, but only if the boss
had a matching linked-node configuration (for both echomail and
netmail).

This commit also re-thinks commit ffe69b43 (for Alterego) which
would not route a point netmail if any our local AKAs matched the
destination address, igorining the point value. I think what was
intended here (I coudln't locate the original enhancmenet request or
issue), was to not route if a local AKA was the *boss* of the point.
And with this commit, that's now how it now works.

As before, "test results appreciated".

No functional change.

Interestingly, gcc version 12.2 and MSVC 2019 had no problem with this code.

Display a progress bar too.

Tested with this:
wget --content-disposition --post-file=nodelist.010 http://synchro.net/fido-nodelist-syncterm.ssjs

Migrated rcpt() to mailutil.js parse_mail_recipient()

Also close the syncterm.lst file so we can read it completely after
load()ing this script.

The validation user (required new user feedback user number) and error notification/level settings don't make sense under node settings in today's world where all nodes typically run on the same system and serve the same BBS.

Moved from SCFG->Nodes->... Advanced Options to (new sub-menu) SCFG->System->Notifications. Likewise, these 3 settings (valuser, erruser, errlevel) were moved from node*/node.ini to ctrl/main.ini.

If you're already running v3.20a, then you'll want to make sure you set these in SCFG->System->Notifications how you prefer them as the migration (now handled in upgrade_to_v320.js) won't have been done for you automatically. The default is no-new-user-feedback required and no-error-notification user set.

Added a prompt to the SCFG setup wizard to prompt for this setting since it still is a FAQ.

Other cosmetic changes to SCFG help and setup wizard.

Updated System Operator help text.
Fixed line-wrapping in other help text.
Provide the UTC offset string to edit, even when 0.
Make the abort/restart wizard options more clear.
General beautifications of the wizard.

I'm not sure what was going on with this addition of 6 when mouse is enabled (and didn't check for WIN_DYN flag set!), but is wrong. And we need to add 4 to the title_len when figuring out the centered-offset.

After the move to 64-bit upload/download byte counts, these integers are different width than 'long' on 32-bit builds (e.g. Windows), so these numbers were wrong on all but 64-bit *nix builds.

The change here also uses the cool byte_estimate_to_str() function so that large byte totals are not expressed in 'K' but rather 'M', 'G', 'T' etc. suffixes.

The formatting is otherwise consistent with the pre-existing log line format save for the use of an uppercase suffix now.

Before:
@- 02:19p  T: 12   R:  0   P:  0   E:  0   F:  0   U:  0k 0   D:420k 1
After:
@- 02:07p  T:  0   R:  0   P:  0   E:  0   F:  0   U:  0K 0   D:420K 1

Before:
@- 02:23p  T:  0   R:  0   P:  0   E:  0   F:  0   U:  0k 0   D:1359k 1
After:
@- 02:26p  T:  1   R:  0   P:  0   E:  0   F:  0   U:  0K 0   D:1.3M 1

This fixes issue #519. I'm glad to hear that sysops still use these log files!

Publish all login-failures to this new topic.

This commit also includes a few 64-bit free disk space fixes in the FTP server.

Very similar to iniGetIntInRange(), but the default value is only returned
if the key or value is missing.

... but not for GCC or Clang interestingly enough.

This kind of sort of matches the SBBSCTRL Config Wizard flow and set of
settings now.

Pretty neat the stuff you can do with UIFC it turns out.

Also fixed a typo here and there and default to the currently-configured
deleted-message-viewing policy and stuff like that.

The title isn't displayed in this mode, so the title length is 0.

Why is title being strdup()'d here? Something to look into.