I don't really like this as-is because it pins a specific (dev!) version.
In a super ideal world, our target platforms would distribute stem
packages that have the Timeout exception added. But that won't happen
for a while. In an ideal world, stem will have hit 1.7.0 with the Timeout
exception and we could require at least that.

Maybe this isn't so bad though? Anyway, I gotta get these Travis tests to
pass!

GH: ref #162

Not currently properly checking that stem is a new enough version.
It needs to be 'git clone'd and installed manually ...

Added in [0] and small fix in [1]

[0]: https://gitweb.torproject.org/stem.git/commit/stem?id=8a065f42952c9dc9762eaebe4d3fa48210783998
[1]: https://gitweb.torproject.org/stem.git/commit/stem?id=60f034ad8b9c3aa48e7e2ecb0a2e159b6ed5bc71

GH: closes #157

There was no such thing as a session.timeout, so it was being ignored.
The timeout has to be set on each request, so add helper funcs to always
add a timeout value.

It was easy too! Just an issue with Result* class no longer taking
a server_host but a dest_url instead.

GH: closes #149

Also the consensus weight of each

GH: closes #142

GH: closes #137

on our own terms. There are apparently cases when Tor won't stop trying
to build a circuit at CircuitBuildTimeout. One such case is when it is
having trouble connecting to the first hop relay.

It seems to wait on TCP to say whether or not the connection is made,
and TCP doesn't come back until after 2 minutes on my machine. That's
just a theory. It could be Tor internally wants to wait 2 minutes before
giving up, but my money is on TCP.

Anyway. Make the logic in build_circuit_impl 10x harder to understand by
doing some "async" waiting ourselves instead of letting stem handle it.
The logic is inspired by the stem code for extending circuits[0].

[0]: https://stem.torproject.org/api/control.html#stem.control.Controller.extend_circuit

Add to that func the timeout parameter

GH: closes #138