Clock: Fix rare race condition with accurateForwardProgressingMillis
Clock: Fix rare race condition with accurateForwardProgressingMillis

Because this function split the update to `nowNanos` and the read from the volatile there was the possibility that the read might read a value lower than a previous call.
For example if two threads:
* Thread A gets into accurateTimeNanos and has read the nano time, but is interrupted before it can write the value
* Thread B gets an updated nano time and commits the write but is suspended before read
* Thread A resumes and writes in the previous time value
* Thread B now reads thread A's write, possibly providing an accurateForwardPregressingMillis that is previous to a previous read

This is obvious a very hard to hit race condition, but has been witnessed.
This fix puts the read and write in such a way that the original System.nanoTime() read is used for evaluating the results rather than another read to `nowNanos`.  Making forward progression garunteed because System.nanoTime() is garunteed.

jentfoo/threadly,threadly/threadly