Fix overflow in timestamp calculation

[bugadani]

This should fix #285 - there's no more multiplication, so there should be no more overflow, either. Still testing the before state though just to make sure.

The original time keeping didn't panic for the same multiplication, because:

• The global incrementing compiled down to an addition with a constant (2AAA_AAAA I believe)
• The cycle counter is 32 bits casted to u64, multiplying that with 40_000_000 results in a 64 bit number without overflow, which was then divided by 240_000_000 without problem
• The results were then the sum of these two values

Why the previous code panicked:

• The overflow counter and cycle counter were added before the multiplication.
• The compiler didn't turn * 40_000_000 / 240_000_000 into a division by 6.
• After a few cycle counter overflows (after the 108th I believe), the multiplication caused an arithmetic overflow.

[Dav1dde]

I've been running this for over an hour now and can't reproduce the panic.

[bjoernQ]

won't be able to fully test this during this week but given the code and the check by the original issue author this looks good to me