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.