Don't use Capture as a return value

By returning Capture (or future thereof) we have the burden to preserve type safety. If the change this we can let the client handle this in a safer and easier way:

Capture<List<String>> capture = Capture.empty();

http.get("/").dispatch(series(),
        on(SUCCESSFUL).call(capture),
        anySeries().call(fail))
        .get(10, SECONDS);

capture.retrieve(); // throws NotReadyException vs EmptyException

Benefits

• completely type safe
• no unsafe casts
• easy to understand for clients
• API is now 100% callbacks
• does not even need to be part of the core API (even though it probably will)

This will complete get rid of the problematic of #114.

• externalize into own module: riptide-capture

[whiskeysierra]

The factory method for that could be in Capture already:

public Future<List<String>> remote() {
    Capture<List<String>> capture = Capture.empty();

    final Future<?> future = http.get("/").dispatch(series(),
            on(SUCCESSFUL).call(capture),
            anySeries().call(fail));

    return capture.adapt(future);
}

[whiskeysierra]

There will be cases where clients want a synchronous response, in those cases a callback-style API is not very user friendly. This is the reason why we have capture in the first place. I see it as a usability extension to make synchronous return values easier.