Refactoring BackToTheFuture

Hello committers.
This pull request contains two things about refactoring `BackToTheFuture`.

#### Eliminated `ExecutionContext.Implicits.global`
`ExecutionContext.Implicits.global` is good for normal use case.  But I think it is not good for async library.

It's because  `global` execution context is concrete implementation and has its characteristics in parallelism.  This tries to keep the CPU(cores) busy. Therefore this leads to limit parallelism.  I think async libraries shouldn't force users to obey this specific parallel execution semantics.

Please refer to my [gist](https://gist.github.com/everpeace/8630941f4c4e8f8a47ac) for detail.  I wrote sample program to show the difference between execution contexts.

#### Changed to use `JFuture.get(timeout, timeunit)` instead of `JFuture.get()`
`java.util.concurrent.Future.get()` doesn't guarantee to stop.  This can possibly block forever. Returned future itself can be timed out with `Await.result()`.  However, this doesn't stop/interrupt `get()` thread. Consequently, this thread will probably leak. Particularly, If the future returned by `org.apache.mesos.ZookeeperState`, this blocks forever in `get()` method when Zookeeper is dead.

To control timeout amount, I introduced `BackToTheFutureTimout` case class.  To specify timeout, Please inject implicit `BackToTheFutureTimeout` value, or `import mesosphere.util.BackToTheFuture.Implicits._`.