add Tor support: onion listeners

My plan here is to add a --tor flag, which will:

• use Tor for all connections to the Rendezvous Server (txtorcon will be asked to create a new Tor instance)
• for Transit, ask txtorcon to create an ephemeral Hidden Service, and use tor:XYZ.onion:PORT as the “direct hint”, instead of scanning and revealing local IP addresses
• continue to advertise the Relay Server as the “relay hints”
• use Tor to connect to the Relay Server, if a direct connection doesn’t succeed

If both sides are using --tor, they should be able to connect with the HS “direct hints”. But if only one side is using Tor, the other won’t be able to use the HS, so they must fall back to the relay.

[meejah]

I have tested it, and Tor support works.

[warner]

reminder to myself: meejah says the best API in txtorcon-0.15.0 for this is probably:

TCPHiddenServiceEndpoint.system_tor(
  reactor, 
  UNIXEndpoint(reactor, "/var/run/tor/control"),
  public_port=RELAY_PORT,
  hidden_service_dir="/tmp/foo",
)

Also, assuming that a side which doesn’t use --tor isn’t capable of using tor hints, we’ve got nine cases to deal with:

		(Receiver Abilities)
(Sender Abilities)	rx=public-IP	rx=private-IP	rx=tor
tx=public-IP	direct	direct	direct (torified)
tx=private-IP	direct	relay	relay (torified)
tx=tor	direct (torified)	relay (torified)	HS

If the non---tor side is able to use Tor (but we only spin up the HS if we’re restricting ourselves to --tor), it looks like:

		(Receiver Abilities)
(Sender Abilities)	rx=public-IP (+tor)	rx=private-IP (+tor)	rx=tor
tx=public-IP (+tor)	direct	direct	direct (torified)
tx=private-IP (+tor)	direct	relay	HS
tx=tor	direct (torified)	HS	HS

If we decided to aggressively spin up the hidden service any time we can, even if we have no idea if the other side can use it, we could flip that middle private+private case to HS. But that doesn’t feel like a win… I suspect the number of times that will be helpful is fairly small.