Expansion to the utilities provided by Clock
The old methods of returning time could go backwards if the system clock moved backwards.  This provides the ability to get a constantly forward moving time.  It also provides the ability to get a reference of how long the Clock class has been running (that way if you load Clock at the start of the JVM, you can easily know how long the application has been running).

The old functionality has not changed, and has no additional load implications.  Instead this forward only design lazily updates it self if it finds that it is too inaccurate.  Thus putting the extra burden on those calls.  Because those calls have more burden I have not decided exactly how this fits into solving #109, but it at least provides us a foundation and starting point (without compromising anything we currently have).)
Fix for updating the nano time in case the milliseconds move backwards
Some changes based off benchmarking the new forwardOnly functions
While the forwardOnlyLastKnownTimeMillis is SUBSTANTIALLY faster than calling System.nanoTime() (about 20 times faster), it was still about 17 slower than the old lastKnownTimeMillis.
Because we feel it is important we fix issue #109, we definetly want to use these new functions.  But we did not want to take the performance impact of these changes.
So this change makes it so that the regular thread (which runs every 100 milliseconds) does two JNI/kernel calls to get the current time millis, as well as now the current nano time.  This way the calls to get the forwardOnly time is almost exactly identical to the counterparts to which use the currentTimeMillis.
I was hoping to avoid to do both system calls there, as I feel a lot of people may only use one or the other.  But I see no other option.  It was issue #109 which really convinced us to make this change.  Since we need to fix this in threadly, and since threadly will be dependent on more the nanoTime than the currentTimeMillis, we figured the likely hood of someone using threadly just for the Clock class was pretty low.

Ultimately it comes down to depending on your use case, determines which one is better for you.  So we are optimizing for the threadly use case, and hoping that optimizes for people who are using threadly as well.
Merge pull request #110 from jentfoo/Clock_enhancements

Expansion to the utilities provided by Clock