When epoch time crosses over the 65536 boundary, AlarmMgr fails

[gcohler]

When the epoch time seconds value grows bigger than 65536, alarm manager fails. Run the geof/replace-shifts branch's combo program, and watch the console logging, and you'll see the problem within 20s.

I think the problem is that secs and sub_secs are combined into ticks -- and that ticks therefore needs to be a u64 (or i64) to be able to avoid wrapping. The same might apply to secs256 units.

My overall suggestion is to get rid of secs and sub_secs and secs256, and to store time in an i64 (more in keeping with zig's std.time). In that way the arithmetic will be handled properly, and we'll have a more common time unit (milli-, micro-, or nano- seconds), and we can adjust the underlying hardware's time at the lower levels of the code, and applications will not need to know the underlying units.

In this light, one might consider AlarmMgr to be an application that should not need to deal in ticks or secs256 or anything other than milliseconds.