Effect-based HTTP client with re-auth and retry support

This should be good for review again.

Note that Effect 0.1a5 now has a generic "retry" function that knows how to retry any effect, which means this code doesn't actually need to do anything to support retries (other than use Effects).

_some_ of the code in otter's retry.py may be useful in that context, but a lot will probably need to be refactored to be useful. (the existing retry.py doesn't support "should retry" checks that return Deferreds, so it's not really useful for the important use case of "check to see if the previous request actually had an effect").
> I'm not sure how the class-based system would actually be better -- it's possible to recompose these functions just as much as it's possible to recompose classes.

Thats true. I meant it purely in terms of argument names. When composing these functions into single functions the argument names can collide. Like if there was `retry_interval` for 2 different functions, it can cause conflict when composing those 2 functions into single `request` function. This is probably just bike-shedding :) since you've rightly pointed out that interval and times is not required since retry will be done only once.