Add/use a new user field: 'reset' which stores the last date/time that the
user record's daily fields were zeroed. Use this new 'reset' date rather than
the last logon or logoff date of the user to determine if the daily fields
need to be zeored or not. The previuos method (checking against the user's
logon or logoff date)  was rife with problems that could lead to these 'daily'
(*today) fields being wildly inaccurate - especially when the user only ever
used non-terminal servers/protocols (e.g. the mail server).

The occasional daily stat reset check while logged into the terminal server
(via node_sync()) still exists since its expected that users may be logged-in
across midnight, but includes a fix for the occasion that the user is logged-in
across multiple midnights. Previously, in this scenario, their "in memory"
daily stats would *not* be reset on subsequent days (for the same login
session). Also added a debug-level log message when the new day is detected.
Although we still set the sys_state flag to indicate a new date was detected,
we don't do anything with that flag (since the user reset timestamp is what we
actually want to use for this purpose) - not sure if any JS script might want
to know, so it's still set even though it's not reset until log-off, which
could be after a multiple-day login session.

Other servers/services don't really have a multiple-day user session solution
just yet, but at least when there is user activity that is counted as a daily
stat, then the 'new day' will be detected and the stats reset (both on disk
and in memory). This change was why the adjustuserval() function signature
changed, resulting in most of the changes in this commit (to all the call-sites
of adjustuserval()).

There were some remaining legacy ushort typecasts too, so deleted those.

This investigation and subsequent overhaul was triggered by issue #961 which I
only kind of / sort of fixed with the commit that claimed to fix it. This is
the real fix.