putuserdatetime() needed to take a time32_t argument to be compatible with
Borland C++ Builder. Eventually, when we stop using that tool, we can move
to just 64-bit time_t's everywhere.

parseuserdat() now accepts and optional array of field pointers to populate
for each user field (for use with the new UserEditor.exe).

exempt->exemptions, rest->restrictions, cdt->credits

As reported by Max (WESTLINE)

This would crash/segfault when the .ini files didn't exist

This adds a Ctrl-A code in the notification subject, so needs latest
postmsg.cpp or that Ctrl-A code will end up in your email/inbox too
(not really supported or stripped when sent over POP/SMTP).

We may want Ctrl-A sequences in the telegram subject, but not in the message
subject

Will notify the sysop via email and telegram when a new user account has
been created. For Morpheus (MORPHEUS)

... unless a comma is actually required.

Somehow, new users on Vertrauen *still* manage to answer "Yes" to both the QWK
Networking account questions, accidentally creating a QWKnet account that's
not useful for normal BBS user activities. So print a very clear "alert" style
message making it even-more clear that the account they are creating will ONLY
be useful for QWK Networking activities.

This Coverity reported issue was previously resolved (incorrectly) with
commit d02fc1a2 which also introduced a bug that ate all the unexpected
cursor position report characters (causing issue #304).

The correct fix was to compare the response length against the buffer size
minus one, to leave room for the NUL terminator.

While fixing this and issue #304, I noticed that this function was using the
response length ('rsp') as both the state machine state and string length,
which didn't work right if a nearly-matching report/response was received:
the x/y values would have been stripped from the response before stuffing
in the keyboard input buffer. So a bit of a refactor here using a proper
state machine variable.

Unexpected characters received (maybe typed by the user) were supposed to
be stuffed in the keyboard input buffer using ungetstr(), but the input string
was cleared rather than NUL-terminated before logging the expected character
and calling ungetstr(), so nothing (a blank string) was logged and nothing was
stuffed in the keyboard input-buffer in this case. Just an off-by-one bug.

This should fix issue #304. Thanks to Keyop and Nelgin for their persistence
in reporting and testing (in #synchronet at irc.synchro.net).

I didn't look closely enough at which write() call I was instrumenting.
This is now more useful, though I think we already found the root-cause
based on different log output ("Unexpected ansi_getxy response").

This just resulted in a lot of unhelpful noise in the log output

When reading and writing characters to chat files, log each with a debug-level
log message. If a read or a write fails, log with an error-level log message.

This will hopefully help root-cause and resolve issue #304.

... for proper error reporting, at least in the terminal server.

Also define/use a macro for the user base filename (now user.tab, not user.dat).

instead of USER_RECORD_LINE_LEN

and then unlocking again. So... make readuserdat() optionally leave the
record locked, reducing a lot of unnecessary lock/unlocking in here.

Move the user field index definitions to userfields.h