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.

New LINEDELAY and LINEDELAY:n @-codes
Another way to pace the terminal output of long display (e.g. ANSI) files. LINEDELAY enables a 1/10th of a second delay before the sending of all LF chars. LINEDELAY:n sets the line_delay duration explicitly to a value in 1/100ths of a second units. So LINEDELAY and LINEDELAY:10 are equivalent. LINEDELAY:0 turns line-pacing off. The original line pacing value is always restored after a printfile/putmsg operation.

New JS console.line_delay property (milliseconds) to control via JS. Setting this to a really high value would be bad. Some range enforcement should be added to this and many other console control values (TODO).

Note: this centering logic does not know the expanded-size of the @-code, so use a fixed-length @-code (e.g. with padding) or use the 'C' @-code format modifier instead.

Fix issue #418

To address CID 345626

When printing a PETSCII Sequence (.seq) file, count the lines/rows and columns similar to how we would if we were using outchar() (but we don't, we use the lower-level outcom() to bypass any translations).

This is related to issue #325:
PETSCII seq files seem to display just fine, the problem I saw was with the auto-pausing (e.g. before a screen-clear) after displaying them.

Inspired by Blocktronics (and other ANSI art group) packs' FILE_ID.DIZ/ANS files:
* Support (and prioritize) FILE_ID.ANS
* Convert ANSI color/attribute sequences in DIZ files to Ctrl-A equivalent (uses SAUCE width and ICE color, if specified)
* Don't treat DIZ as a series of lines, they're not always nowadays.
* New putmsg() mode: P_INDENT to print files indented by current column
* Display full (up to 64-char) filenames in lists when using 132+ column terminal.
* Use the Author, Group, and Title fields from the SAUCE if present/non-blank
* 2 new text.dat strings: 301 (FiAuthor) and 302 (FiGroup)
* Also fix bug with repeated Cost header field on bulk-uploaded files.

I know this'll break the *nix build (sauce.c dependency), but I'll fix that next.

This allows us to ignore markup codes in a string like: "/sbbs/ctrl/*cnf*"

Addresses false-positive matches in URLs (e.g. https://minftn.net/) where the second slash was being interpreted as a the beginning of an italic markup.

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.

So you can do stuff (*like this*).

Also, we don't need to heavily scrutinize the closing tag when we come upon it because we already determined it was valid before we accepted the opening tag/character.

Defaults to "Off" ("No") and can be set per-sub-board to either:
- "Yes" parse/apply markup style to displayed message text while still displaying the markup tags
- "Hide" parse/apply markup style to displayed message text and hide (don't display) the markup tags
- "No", treat marked-up messages the same as any other message text, same as before.

The supported Markup tags at this time are:
#bold text#
/Italicized text/
_underlined text_
#inverse text#

Now, ANSI-BBS terminals (and Synchronet) do not support the concept of italic or underlined text (at least, not yet) - so those styles become combinations of the blink and high-intensity attributes which can be used to choose alternate fonts and this works well.

These 4 styles were chosen to be compatible with GoldEd's "Style Codes", though GoldEd is actually very configurable in its support of these tags/codes and its possible we're not 100% compatible. For example, GoldEd (and SemPoint) both support the combining of tags/codes to created combinations of styled text - Synchronet does not (this is consistent with Mozilla/Thunderbird's "Structured Text").

Multiple words can be styled with a single set of tags, but the first and last word must be delimited by white-space (this is not consistent with Markdown).

Multiple lines can be styled with a single set of tags, but not multiple paragraphs (this is consistent with Markdown).

The rules I chose were to minimize false positives but maintain some interoperability with GoldEd and Thunderbird with a familiar/common tag syntax.

putmsg(), used to display messages and display/menu files, will no longer pass-through the ANSI sequence ESC[c (found in some corrupted ANSI posts to fsxNet->FSX_BOT echo) to the client terminal since this will stimulate a (unwanted) response from the client.

I do wonder if the outchar_esc value check should be == here instead of >=, but I'm not familiar with the string and SOS states. I wonder if any display files sent from the BBS would ever include those sequences.

No functional change with regard to the ANSI output state, just making the code easier to read.

Removed the conversion of `[ and \xFA[ to \x1b[ in putmsg(). This unexplained output translation has been supported since at least v2.xx and I have no recollection of exactly why it was added. If I recall correctly, some BBS software at some point in time sent ANSI-encoded messages into message networks by translating the ESC (\x1b) character in the ANSI sequences to either ` or \xFA in the process. This "feature" seems like it would still work, but it's completely undocumented and I have no idea why it was added (and seriously doubt anyone relies on this behavior), so I'm removing it. If anyone misses this feature, I'll happily add it back, but I'm skeptical that'll happen.

Fix problem introduced in
b1ecd9b6 (August 8, 2019)

When sbbs_t::printfile() is used to display a file that is < 2MB in size
and the P_OPENCLOSE mode flag was not specified, the file is read and
displayed one line at a time. This allows for the quick display of very
large files. This was accomlished by calling sbbs_t::putmsg() for each
line. Unfortunately, putmsg() would save and restore console mode flags
like the auto-screen pause control flags stored in sbbs_t::sys_misc
so this would render some features like the POFF @-code, inoperable.
This problem was reported by WitNik with files displayed from
Bulleeye! Bulletins.

Other issues were discovered with the WORDWRAP/WRAPOFF @-codes.

Fixed with the addition of sbbs_t::putmsgfrag() which is used by
printfile() to display a message fragment (one line) without
saving/restoring console state flags.

If Ctrl-A~ is followed by a control character (e.g. CR or LF) or the end of the string/file, then create a hungry hotspot for the line that sends CR when clicked.

If ^A~or ^A` is followed by a ctrl charcter, don't treat as a hot-spot. This helps to insure that if there are any .asc/.msg files "in the wild" that have a sequence of ^A`^AL (home-cursor, clear-screen), they'll still render as before
the introduction fo the strict hot-spot ^A` sequence.

Both hungry/liberal hot-spots and strict hot-spots can be defined now, at the same time. For Nelgin.
Use ^A` to define a single-char strict hot-spot using Ctrl-A codes. Unfortunately, this usurps the "home" Ctrl-A code which nothing seems to use but has now been changed to ^A'.
Use ` instead of ~ in mnemonics to define strict single-char hot-spots (also displays the cmd key in [] instead () on non ANSI/PETSCII terms).
Use @` instead of @~ codes to define strict hot-keys.
Use HOT:STRICT @-code to declare a strict hot-key color.
Use HOT:HUNGRY @-code to toggle back to hungry color-defined hot-keys (the default).
New optional boolean argument to JS console.add_hotkey(), hungry = true by default.

One more method of creating a (single-character) mouse hot-spot since @-codes are not universally supported everywhere or always convenient:
  Ctrl-A~
The character immediately following a ^A~ will be added as a single-char mouse hot-spot.

non-PETSCII (.seq) display files are assumed to retain their attributes between lines, but PETSCII terminals reset the inverse attribute upon CR's, so restore the attribute if it changes unexpectedly. We could make this check only when outputting CR's (rather than all characters), if it's a problem later.

A more convenient method of creating mouse hot spots in a display (e.g. menu) file: New "HOT:<attr>" @-code allows you to define a specific combination of attributes (colors) that will be used to exclusively create clickable command keys or words in a file. Every set of charcters in the display file that uses that specific combination of attributes will become an automatic mouse hot spot. The <attr> is specified using a set of attribte mnemonics (e.g. "YH" for high-intensity yellow), the same set used in attr.cfg and other places in sbbs.

This allows more WYSIWYG style menu editing (e.g. use PabloDraw), you just need to be careful with your choice of colors. You cannot send white-space or control characters with this method and the clickable text is the exact text that will be put in the keyboard buffer.

- hot spots are clickable screen areas (e.g. in menus and prompts) that   generate key-strokes
- commands may be from 1 to 127 ASCII-characters in length
- currently using the X10 mouse reporting mode, may change
- all mnemonics strings (~Example) are automatically hot-spots
- The new ~ @-code defines a hot spot
- Any screen-clear operation clears all hot spots
- sbbs now tracks the current screen (cursor position) row
- eliminated the old "tos" (top-of-screen) boolean (row == 0 indicates "tos")
- created an sbbs_t::ungetstr() method
- keep track if in pause (hit a key) prompt, for special mouse behavior

new JS console object:
- row property
- tos property is now read-only (and deprecated)
- new methods:
  add_hotspot()
  clear_hotspots()
  scroll_hotspots()

redrwstr() gets some UTF8 touch-ups as part of this commit. <shrug>

After displaying a native PETSCII (.seq) file, reset the character set to Upper/Lower for compatibility with the rest of the BBS (some PETSCII Art files change the character set to Upper/Graphics).

the name of a scalar property in either the current scope (by default) or the
scope of the object passed to:
- bbs.menu()
- console.putmsg()
- console.printfile()
- console.printtail()

The 'name' cannot be an array element (e.g. myprop[0]) or a nested object
reference (e.g. myobj.myprop): just a single property name that can be
converted to a string.

Also, bbs.menu() now accepts an optional print-mode argument (default: P_NONE).

- incomplete, it didn't account for the CLEAR @-code which is only handled here
- caused side-effects in that any Baja PRINT function call with a single line
  that contained any  ^A or @-codes would reset the console abort indication
  flag (SS_ABORT).
  Observed: hitting Ctrl-C at while executing the yesnobar.bin or noyesbar.bin
  would leave "Yes Yes No" on the console, for example.
  Solution: use the tos (top-of-screen) state before/after the call to ctrl_a()
  or show_atcode() to determine if the reset-abort hack should be applied.

- new @-code BPS:x (where x is 0/unlimited, 300, 600, 1200, 2400, ... 115200)
- new JS property: console.output_rate
So you can have mutliple output rate changes in a single file by using multiple
BPS @-codes.
Hopefully this doesn't do weird things with non-compliant terminals.

- bstrlen() moved to sbbs_t, accepts an option pmode argument so it can account
  for UTF-8 encoded strings correctly
- JS console.strlen() now accepts an optional pmode argument (e.g. P_UTF8)
- Renamed sbbs_t::utf8_to_cp437 to sbbs_t::print_utf8_as_cp437
- Create/use msghdr_hfield() to perform UTF-8->CP437 conversions as needed for
  printing/copying UTF-8 encoded message header fields.
- Defined XTRN_UTF8 misc setting flag. If a message editor does *not* have this
  flag, it is assumed to *not* support UTF-8. Will likely use this for UTF-8
  doors as some point too (none known to exist, yet).

transfers. These should *not* be included in message text.

support in putmsg/printfile, etc. on per-use basis.
Add per-sub-board P-mode flags (so "Extra Attribute Codes" can be disabled
on a per-sub-board basis).

@-codes are also supported (i.e. displaying sysop-controlled content).

- Export all FIDOCTRL (other FTN kludge lines) to the QWK HEADERS.DAT file.
  These should already be imported if they exist, but were never added during
  export, so untested/new behavior. The control paragraph (kludge line) of
  specific interest here is the "CHRS" (charset) kludge we need for UTF-8.

- Don't use the QWK "newline" character (0xE3) when the message is UTF-8.
  Use bare-LF's instead. This is pretty untested at this point as I will need
  another QWKnet board to post or receive UTF-8 encoded messages to test,
  getting the code into CVS is the first step. At least for now, there's no
  opt-in/out for this behavior. If your BBS has UTF-8 encoded messages, some
  QWK nodes or offline readers may have trouble with packets which include
  those messages. Or they may work fine (but likely display garbage CP437
  chars in-place of the proper Unicode codepoint glyph).

- The beginning of UTF-8 input support in getstr() - which needs more work,
  particularly around character and word deletion and insertion.
- The internal message editor now supports UTF-8 messages and kind of somewhat
  supports inputting UTF-8 characters in message text.

New put/print text flag: P_AUTO_UTF8 which can auto-detect UTF8 strings and
do the "right thing" for the user's terminal. New associated sbbs_t method:
auto_utf8() which automatically sets P_UTF8 for any stirng that begins with
a UTF-8 BOM (ZWNBSP). Else, if the P_AUTO_UTF8 mode flag is set, then
it checks to see if the string contains invalid US-ASCII chars but valid UTF-8
sequences and then sets P_UTF8 accordingly. Used by putmsg() and bputs().

There's a new permuation of bprintf() which accepts a mode argument
(i.e. for P_UTF8) and passes it on to the new mode-capable bputs().

codes.