Handle clock rollbacks

Currently in Censum, the expectation is a monotonically increasing clock value. In reality, clocks are not monotonic and in those cases the clock can travel backwards. This leads to potential errors in downstream calculations. ATM there isn't much that can be done with this except detect it and offer a warning. The NTP RFC specifies jumps of approximately 100ms. NTP favours forward jumps and as it happens, this is the most common use case (generally due to local thermal conditions in the pizza box).

In other cases this is simply a case of log corruption. The most common case is that two separate GC logs have been concatenated together. In this case the most sensible thing to do would to offer a warning that the clock rollbacked back and then halt the parsing.

Start by tracing Censum's GC log parsing and clock-handling paths, then inspect how existing warnings and parse failures are reported. Done means backward clock movement is detected, a warning is offered, and parsing halts for corrupted or concatenated logs.