Have `Buffer` use default executor about tower

[jonhoo]

I'll try to persist some of my thoughts from the Gitter about this change, and also how it interacts with #118.

The proposed solution here is basically:

struct Buffer<T, Request, Executor = DefaultExecutor>
where T: Service<Request>
{
    executor: Executor,
    worker: Option<Worker<T, Request>>,
    // ...
}

And then have poll_ready be:

fn poll_ready(...) -> ... {
    if let Some(w) = self.worker.take() {
        self.executor.spawn(w);
    }
    // ...
}

With #118, the T: Service bound on Worker has to become T: DirectService<Request> instead. To allow Buffer to wrap regular Services, we also provide a DirectedService<T: Service> wrapper that impl DirectService by proxying poll_ready and call to T and doing nothing for the other methods. But Buffer<T> must now have the bound T: DirectService<Request> if it is to contain the Worker instance. While the user can specify that type, they'll have to know about DirectService and the DirectedService wrapper, which seems unfortunate. I don't have a clean workaround for this that doesn't involve Boxing the Worker.

---

As for hiding the concrete task type that needs to be spawned using this approach, I'm not sure how the solution outlined there fixes issue I raise above? We basically already have the proposed wrapper type (Worker ~= MyLibTask), but this still doesn't hide Worker (due to the E: TypedExecutor<MyLibTask<T> bound). It also still reveals the T: DirectService bound, and the DirectedService wrapper, which seems unfortunate. I don't have a way of getting around that though sadly.

One alternative specifically for the DefaultExecutor case would be to have Buffer::new use future::lazy and return impl Future<Item = Buffer>. It's definitely a bit of a cop-out, but saves us from some of these thorny issues.

---

And finally, isn't it a little sad for Buffer to carry along an Executor? It probably doesn't matter too much for DefaultExecutor, but are there other Executors where this might be a problem?

---

Overall, I think we should probably wait to make this change until after #118 lands.