Helpful for a JS batch file transfer menu

Returns count of files removed now (not bool).

This allows GetConsoleScreenBufferInfoEx() to work for palette
changes, allowing Console to not suck.  However, we now prefer
ANSI mode over Win32 Console, so make that so it can actually
fail on Windows of stdout is a TTY and we can't set the
ENABLE_VIRTUAL_TERMINAL_PROCESSING flag.

With this, ANSI mode is used in Windows Terminal, and Win32 Console
is used in Legacy Console, and all should be good with the world.

(as is/was done in useredit.cpp)

Fix the default download protocol columning display (missing final
newline in many cases).

This appears to be have been missed in the conversion from Baja

Reported by vela025

CSI s and CSI u are ANSI.SYS extensions, and aren't needed here.
We're clearing the screen and moveing the cursor anyway.

Not only was it broken when window() is set, it's also broken when
the width is not the full screen width.

We've now disabled pretty much all the optimizations... but it works.

Specifically, make Win32 Terminal output not suck.
If stdout is a tty, set the palette appropriately, avoid using \n
since Windows can't seem to be stopped from expanding it to \r\n
nd brob the Console modes a bit harder.

The window and the screen buffer are two different things... the
screen buffer must always be the same size as or larger than the
window.  Further, there are times where it's not possible to resize
the windown programatically (new terminal for example).

There still appears to be a stupid bug in what I assume is the
Windows Terminal LCF flag implementation which causes writes to
the beginning of a line that occur after a write to the end of the
previous line to be in the wrong position.  If it's not the LCF flag
(which isn't turned on), it's in their wrapping thing which is extra
irritating since I explocitly turn that off.

Almost there, the main issue remaining is when running from a
command-line, it sometimes "unwraps" lines.

Likely still not right though.

Because it screws up the display when you resize the window.

This was a bug in the conversion from Baja and C++ to JS.

Discovered/reported by vela025

Fixes issue were jsexec was used to invoke this script and a ctrl dir
(different than the contents of the SBBSCTRL env var) was passed on the
command-line (i.e. testing purpose). Use the correct ctrl directory.

Create the data/text directory if it doesn't already exist. This dir
is normally created whenever SBBS is run, so it should normally already
exist, but if someone runs this script via jsexec before (ever) running
sbbs, then it's possible the data/text directory does not yet exist.

I'm not sure if the file was renamed at some point or what, but apparently
it's currently named in ALL CAPS.

This was broken when SFTP support was added and wasn't noticed.
Big thanks to Scott Labrecque of ems-bbs.com for noticing!

This doesn't fix the terrible crap Windows does to the contents of
the console yet though (sigh).

These 2 properties, specifically, could be made writable since
1. smb_t.curmsg is a special element owned by the application, not smblib
2. a special sbbs_t.current_msg_number property could be created/used to
   underlie the bbs.msg_number when there's no open message base (by sbbs).

This might be all that's needed to resolve issue #793

The other bbs.msg_* and bbs.smb_* properties are not so easily made writable,
so hopefully that's not desired.

So we need to define the Windows API ourselves. :(

SetConsoleScreenBufferInfoEx() can no longer set colors in the
console palette.  Switch to virtual terminal parsing stuff and send
some ANSI to adjust the palette instead.

And try to make it clear that multiple bases can be passed on the command-line.

This was disabled due to mingw32 limitations, and we use mingw64 now

Fix issue #801

Now that the conio layer is handling translation of character sets,
the key handler in term.c should only handle terminal related
translations (such as backspace to delete).

This fixes bug 159, but there's still some inconsistency across
the various backends on how they handle C0 control characters and
input characters outside of US-ASCII.

Fix for issue #800

Other Ctrl-A codes (e.g. ^A\) might be valid, but they're not attribute
control codes, so their existence would cause this function to return true.

The old code expected the L1 cache to be fairly large, and the
prefetcher to be fairly smart, and did updates by columns to save
some math.  This change performs width interpolation row-by-row
so even the dumbest prefetcher can get it right, and there's no
need to keep the whole source and destination images in the cache.

This may help out older processors when scaling with interpolation
(most commonly used in fullscreen).

It's entirely possible though that this won't be enough and they'll
still need to use "External" scaling.

There are still places where it could be logged in <> (if username is not yet
known).

Add JS console.ansi_getdims()

Use sbbs_t::getdimensions() or JS console.getdimensions() to move user
cols/rows values to run-time console values (querying ANSI terminal if
appropriate/supported).

JS console.pushxy(), popxy(), and gotoxy() all return Boolean now.

sbbs_t::getdimensions() and its JS wrapper is now the proper way to propagate
user's cols/rows settings to the run-time console values. This was done
(post-login) only via use of the TERMROWS and TERMCOLS @-codes in
user_settings.js. Weird.

more than 25 years behind the C standard.