Fix some spelling errors in the javadocs
Fix for unit test failure
Fix to ExceptionUtils.handleException when thread has an UncaughtExceptionHandler set
Previously we would automatically default to the defaultUncaughtExceptionHandler.  This changes it to use the more java designed way, by requesting the uncaughtExceptionHandler that is set for the thread (which will default to the group if none is set, which may eventually default to the defaultUncaughtExceptionHandler).  If none are set, then it will ultimatly print to std error like we were doing previously.  Long story short, java was doing the heavy lifting for us.
Adds "ConfigurableThreadFactory", this allows us to reduce duplicated code as well as provide more functionality for others.
We had a couple inner classes which could be replaced by this implementation.  This implementation also has more configurable options that users can easily take advantage of (instead of having to make their own ThreadFactory implementations).
2.3.0 Release!
Updated versions to 2.4.0-SNAPSHOT for future development
Added a new FutureTask type.  This one executes either from the .run() function or the .get() function (which ever occurs first).
The thought is that once you call .get(), if it has not already started executing the task, we have a thread available to execute it now.  So why just block the thread waiting on the executor, and instead not just execute the task immediately.
This makes sense if you need the result of this before you can continue execution (and the executor may be filled with other, possibly lower priority, tasks).
I decided this was a better name for this new FutureTask type
This resolves #100.  I am resolving this issue half way by allowing you to change the behavior of how we handle the uncaught exceptions.
This allows you to set a threadly specific exception handler.  If that ExceptionHandler is set, then java's built in UncaughtExceptionHandler will never be used or called by threadly (as threadly never allows exceptions to kill threads).
This also fixes a small bug where an UncaughtExceptionHandler throwing an exception could result in a thread death from within the pool.
Added ability to provide ExceptionHandlerInterface implementation from within the ConfigurableThreadFactory
This is a better way to go at string duplication reductions.
Instead of just attempting to duplicate the strings, we also reduce the duplicated logic around verifying these arguments.  The new class "ArgumentVerifier" likely will not be useful to others right now, but it does reduce a lot of code within threadly, and does reduce the jar size a little bit.  It also provides a common language for the messages within the thrown exceptions.
I decided to switch these back from adjusting invalid values to throwing IllegalArgumentException's
This keeps the behavior consistent....if we want to change this, I think we should uniformly change it throughout the project.
2.4.0 Release!
Updated versions to 2.5.0-SNAPSHOT
Fix bug where we may not cancel one of the tasks in invokeAll with a timeout
Slightly simpler way to do this execution
Fix for ServiceWrapper's invokeAny when tasks don't complete successfully
Previously we would stop invokations as soon as one would error out.  Now we respect the original contract where we hold on to failures, and keep trying until we get one that works (or if none work then we throw the last failure we got).
This complicates the code a bit, but it is technically more correct.  I added unit tests to verify this behavior.
This resolves #101...renaming the TaskExecutorDistributor into KeyDistributedExecutor and TaskSchedulerDistributor into KeyDistributedScheduler
These old classes will be removed in the 3.0.0 release
Removed deprecated API's for 3.0.0 release
This saves about 2.5KB in the jar size (which obviously does not include the unit test code)