Fix for a slightly unreliable unit test as well as reduced unit test code duplication.
Minor spacing change
Additional javadoc details around task priorities and how the thread pool handles them.
Reduced usage of the ClockWrapper.  I changed ClockWrapper to do just one thing, which is "semiAccurateTime".  Any updates, or checks for last known time must go through the parent class "Clock".

This also solves an issue where the Clock may update while we have requested no updates to occur.  Causing a jump of time, and possibly causing an item to be placed further back in the queue than it actually belongs.  This would occur by an item being either inserted or repositioned (for recurring).  While doing the binary search to find the insertion index, if the clock changed during this search the item may be placed incorrectly.  I warrent this is very unlikely unless you have tons and tons of tasks.  In addition since we would update the clock manually before doing the search, hopefully this risk not cause a problem.
Fix for unit tests running after the ClockWrapperTest
Javadoc improvments and clarifications.  This provides additional details and in a couple places fixes some minor details in the javadocs which were incorrect.
Changed the Threadly interfaces such that they will all return ListenableFuture's over the more basic Future.  Since ListernableFuture's extend Future, this is a backwards compatible change.

This allows for some simplification, as well as some code reduction.  It would only be a problem if someone wanted to implement one of the threadly interfaces, but did not want to use ListernableFuture's (of course I don't understand why that would be the case, so I am just going with the simpler and less code option).
A little progress towards Issue #50.  This combines SimpleSchedulerLimiter and SubmitterSchedulerLimiter into one (simpler) class called "SchedulerLimiter".

This reduced a lot of code, as well as provided a MUCH simpler simplementation compared to what SubmitterSchedulerLimiter used to be.  This change also exposed a defect in PriorityScheduledExecutor with removal of callables which are wrapped in runnables.  This commit fixes that in order to fix the unit tests.

We still need to look at what we are going to do for the PrioritySchedulerLimiter, but I may wait on that for now, since those changes will be more dramatic (and possibly more risky).  It was important for me to do these before 1.0.0 release because these changes break the API/interface.
Because the PrioritySchedulerLimiter was the only user of the AbstractSchedulerLimiter.  I decided to bring the code within that class back into the PrioritySchedulerLimiter.

There are no functional changes, but since Issue #50 wants to change how we are doing the PrioritySchedulerLimiter, it made sense to bring the code in question closer together.
Looking at removing the testable scheduler.  It complicates the implementation, and adds a lot of code.  Furthermore I don't know of anyone currently using it, and although I think the implementation is solid, I worry about furture reqressions with other areas of code (see issue #51).

So I am just experimenting at what the implementations would look like if this was removed.
Removal of the VirtualLock infastructure since there is no longer any testable locks.  We are now just returning Objects in their place to be synchronized on.
A couple javadoc fixes for the recent changes.
Updated readme and descriptions based off the recent removal of code.
Constructor cleanup now that the StripedLock is more of an internal thing, and the user has no reason to pass it in during construction.
Merge pull request #53 from threadly/TestableScheduler_removal

TestableScheduler/VirtualLock/Virtual(Runnable/Callable) removal
This resolves #51.  This dramatically simplifies the PrioritySchedulerLimiter and reduces the code involved by constructing the returned future at submission time, and avoiding the whole "FutureListernableFuture" thing.
Removing these "FutureFuture" implementations.  They are complicated, and hard to use correctly.

In addition now that threadly no longer needs them, I think it would be advisable for others that need them to look towards other solutions.
Slight change to the description of the project.
Added the ability to get the current running count, even if not using the StatisticTracker pool.
This is no longer necessary with the removal of the TestablePriorityScheduler