Little performance improvement by avoiding synchronization here and instead using LockSupport
This commit is both good and bad.

The good:
* FutureListenableFuture no longer blocks on addListener if the parent future has not been set
* FutureFuture's implemention does not have to synchronize so much
* FutureFuture's implement of cancel and isCancelled is now 100% accurate if the parent future was canceled

The bad:
* FutureFuture is less likely to be able to cancel.  If you call cancel before the parent future is set, then we can not guarantee we can cancel the parent future.  So we no longer make an attempt to cancel the parent future when it is set (since we already told you it is not canceled).  I am not super happy with this, but decided it is better to not cancel a future, than it is to tell them we canceled it (and was actually unable to do so).
Added javadoc to fix checkstyle warning
Increases our chances of being able to cancel tasks through the future returned by Limiters/sub pools.  Currently this only works for runnables (and not callables).  Callables present some more extensive challenges.
This was a mistake in adheering to the javadoc.  We need to cancel any futures which have not completed.
This resolves #41  This fixes it for callables, I solved it just about how I originally described it, but will be able to avoid the instance of check for the most part.
Need to catch a couple exceptions here which can happen during shutdown
0.7 release
Updated to snapshot for 0.8 release
Merge branch 'master' into experimental-more_concurrent_scheduler