redmine6554: Restore support for denormal times in laterthan() and add it in on().

If someone specifies a date-and-time while adding an offset to one of
the components (e.g. to specify a given number of days, or hours,
after some specified event whose date and time are known) we can
handle that, doing The Right Thing (as handled by mktime, normalising
the date-time sensibly), by simply not forbidding it.  Recent changes
to laterthan() removed support for this; on() has not previously
supported it; but it makes sense to support it for both, so I'm
allowing both to take values in a wide (but still limited) range.
Also, move on()'s argument description to alongside those for the
other time-related functions with the same arguments.
Indeed, although it could be made safe quite easily, although it's actually 2038 that the problem lands (I used 2037 here precisely because the tests use various dates throughout the year and some of those won't work in 2038).
The problem is that 32-bit systems aren't "Y2K38 safe" (and pretty much can't be) and we have to be capable of running on such systems.  We should probably look (sometime in the next 23 years) at changing the limits (in `libpromises/cf3.defs.h`) on the range of int to depend on architecture; use 0x7fffffff on 32-bit but 999,999,999,999 (or some similar silly big number) on 64-bit.  Just so long as we do so consistently ...

We should probably also systematically change everything that handles int values to use some typedef'ed name that's bound to a suitably big integral type.