Fix for unit test regressions
Because the alwaysProgressing time is based off nanoseconds, it may not have progressed forward even though the accurateTimeMillis has progressed forwrad.
This resolves #109
We now use the new clock functionality for all usage in threadly where time progression is important.
We had to update the unit tests to use the same functionality because it could cause unit test failures if currentTimeMillis progresses at a different rate (we would sometimes see a 1 millisecond difference).  We think that is most likely caused by "flutter" within the currentTimeMillis which is not present in the nanoTime calls.
This has no performance impacts on linux, but will be slightly slower on windows.  Java's thread pools use nanoTime as well, so we are still no worse than them (we are arguably better due to the need to have less nanoTime calls).
This had a lot of unit test verification, so we also fixed some unit tests that would fail on a very slow machine (to help ensure we are having correct timing).
Increased timeout on unit tests due to slow ec2 machine