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

GH: closes #126

the source of many future bugs due to side effects and assumed
behaviors.

Since connect_to_destination_over_circuit already determines if a
detination is usable, it made sense to move it and use it in more
places.

Fun fact:
During the process of determining if a destination is usable, a stream
is created to it. Given the same requests Session object, this stream
can be reused (and is by default in requests code) to make additional
requests to the web server. This is why the function is called
connect_to_destination_over_circuit. When first written, determining if
a destination is usbale was the side effect while opening the socket to
the destination was the primary effect.

GH: ref #138

GH: closes #134

GH: ref #134

GH: closes #135

Stop saying [broken] all the time. We get it.

GH: closes #140

GH: closes #144

"Hey, it's essentially a rebase, you just have to deal with all the
conflicts at once instead of one at a time"

 Conflicts:
	sbws/__init__.py
	sbws/config.default.ini
	sbws/core/scanner.py
	sbws/lib/helperrelay.py
	sbws/util/stem.py
	tests/testnets/.gitignore
	tests/testnets/simple.common/01-gen-configs.sh

This torrc line
    FooKey valuea   valueb
Becomes
    key="FooKey", value="valuea   valueb"
Instead of
    key="FooKey", value="valuea valueb"

I don't think Tor ever cares, but just in case.

Thanks, @teor2345

If there's still ExitPolicy related issues as discussed on IRC, trac,
and this GH issue tracker, they will be handled separately in the branch
that actually hits the issues.