Catch more exceptions in async client code

Some experimenting with the load generator and also a bug report from Martin indicated that there were cases where exceptions were getting thrown in async client handlers that were not caught, and could prevent us from ever firing either the success or failure callbacks for a client call. This diff tries to catch all of those cases, to guarantee we'll fire one of the callbacks.
Improve exception handling for NiftyClient connections

- Translate all exceptions to TTransportException
- Catch any exceptions in the ChannelFutureListener to make sure we always set a value or exception on the ListenableFuture
- Catch failure of cancel() call in the ChannelFutureListener to make sure we *always* set a value or exception on the ListenableFuture
Upgrade to facebook-oss-pom v7
Change NiftyProcessor.process() interface method to return a ListenableFuture

This is to support asynchronous processors (soon to be added to swift). The processor should return a ListenableFuture<Boolean> instead of a boolean, and set that future when the return value is ready.

Processors which are not going to do asynchronous processing (e.g. processors generated by standard thrift compiler) should just use Futures.immediateFuture() to construct their return values. The NiftyProcessorAdapters utility class will handle this automatically for processors deriving from the standard thrift TProcessor interface.