Robocup bug fix of Thunderloop clock

[mkhlb]

Please fill out the following before requesting review on this PR

Description

next_shot is supposed to be an absolute time at which the next thunderloop iteration is supposed to run. Thus to maintain a constant interval inbetween iterations it should be incremented by a constant amount. Before this PR thunderloop would run at shorter intervals if it took longer to run the current iteration.

The fix done in 5828d4e was different, changing the entire Thunderloop clock to use a relative sleep. Feel free to comment if you believe that was a better fix than this.

Testing Done

No on robot testing done yet, but Thunderloop builds fine.

Resolved Issues

Length Justification and Key Files to Review

It is not long.

Review Checklist

It is the reviewers responsibility to also make sure every item here has been covered

• Function & Class comments: All function definitions (usually in the .h file) should have a javadoc style comment at the start of them. For examples, see the functions defined in thunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.
• Remove all commented out code
• Remove extra print statements: for example, those just used for testing
• Resolve all TODO's: All TODO (or similar) statements should either be completed or associated with a github issue

Again compare with 5828d4e as that has an alternative fix with an equivalent effect.

[notion-workspace]

Thunderloop clock fix

[williamckha]

Side note, we should consider using std::chrono::steady_clock and std::this_thread::sleep_for instead of the libc functions. Then we could also get rid of the helper functions for converting timespec to milliseconds/nanoseconds and just use the std::chrono API

[itsarune]

looks good, pending CI