adjtime(2): Handle negative tv_sec and tv_usec.

Previously I clamped these to avoid dangerous arithmetic overflow.
But I assumed sensible values should be nonnegative.

For tv_sec, this assumption was just wrong -- the adjustment may be
negative.

For tv_usec, this assumption is...not wrong, but also not right.
tv_usec is not _supposed_ to be negative (by POSIX, the type need
only represent values in [-1, 1000000]; semantically the member is
supposed to be a nonnegative number of microseconds below 1000000),
but ntp abuses it to hold negative values, for reasons unclear -- the
same effect could be had by subtracting one from tv_sec, and adding
1000000 to the negative tv_usec.  However, let's not break existing
ntp userlands...

(riastradh)