This is an attempt to resolve #54.

We solve it by tracking how many tasks are waiting for a worker.  If there are any waiting, we just start workers (as long as we remain under our max pool size).  That way it puts the burden on the thread increasing the max pool size, instead of in the normal run time path of how we consume workers.

Because of this change I removed the synchronized block for makeNewWorker and getExistingWorker.  The lock is REQUIRED, but if your relying it to lock at the call point, then it will break the code comitted here to make sure threads are not blocking.  This is demonstrated in the following situation:
* Pre condition: All workers are busy handling tasks and so none are available
* Thread 1 increases max pool size, but no one is blocking waiting for a worker, so no workers are started even though none are available
* Thread 2 called to get existing worker, and assume we lock after the call, so this thread is blocked waiting for the lock
* Thread 2 wakes up after Thread 1 releases the lock...but no workers are available since none were started.  So we block for the maxWaitTime.  In order to prevent this we had to lock before we made the decision to call getExistingWorker (ie verified the core size < max pool size, and we should not create a worker instead)

Because it does not make sense to lock here any more, but in practice we must lock, I created a "StrictPriorityScheduledExecutor" which can be used to verify these assumptions.  It does not make sense to verify these things always because the only way to violate this rule is to extend the class.
Added a couple unit tests to verify the original behavior and fix for issue #54
Merge pull request #55 from threadly/issue_54-stuck_jobs_on_max_size_increase

This resolves #54.
Changed the name of the calls in the StatisticTracker for getting stats on how often a worker was avaialble
I also made a change to the DynamicDelayQueue to remove the spin lock.  This simplifies the logic a fair amount, and in mosts cases actually improved job run time accuracy.
Added an optimization for the ConcurrentArrayList reposition functionality.  This way when we reposition from either the front or end to the respective opposite, we may be able to avoid an array copy.
I implemented this as such so that we try to only do these extra checks if there is a possibility we can gain from the improvement (which makes the code slightly more complicated to look at, but should perform well).

I also fixed a unit test failure that could occur in the ClockWrapperTest
Removed the option to create a "non-thread safe" NoThreadScheduler.  The overhead of synchronizing is probably not a big deal if there is no lock contention, and this makes our unit tests and code quite a bit smaller and simpler.
In addition I improved the remove functionality to use the same remove logic that the PriorityScheduledExecutor was using (and thus traverse the containers if they exist)
More love for the NoThreadScheduler, better error checking to match the other schedulers.  Also added a unit tests, and fixed a bug where recurring tasks could not be removed while they were running.
Fix for synchronizing on the wrong object from my last push.

Renamed a few inner-classes for clarity
Some additional unit test coverage
This resolves #56.  Benchmarking showed minimal (if any) conditions where using an ArrayDeque would be slower.  And other situations where there is a substantial improvement.  So switching out the implementation for an ArrayDequeue.
Removed the CallableDistributor.  This was created before threadly had first class Future support.  Now that future support is included this could easily be done within code by using a blocking queue of futures, or a hash map of futures.
Added @since tags to the class javadocs (so we know what was included when).  I am defaulting these all to 1.0.0 release, even though many were introduced earlier (just don't want to track when all were introduced)
Whoops, logic error with ! when should be == (yay unit tests)
1.0.0 Release!
Updating back to the snapshot versions for the next release
Updated README with new litecoin donate address
Improvments to the unit tests when verifying the futures
Small cleanup, trying to be consistent in checking everything possible before the synchronize block
Fix for a possible unit test failure
Improvments for scheduling on a limited sub pool.
This provides performance improvments for scheduled (and recurring) tasks by attempting to run on the delayed runnable thread, and only queuing if forced to do so.  Previously this would always due the worst case situation and queue after the delay has expired.  This commit also reduces code duplication by allowing the PrioritySchedulerLimiter extending from the SchedulerLimiter.
I also expanded and improved the unit test code, to make sure we get full coverage.