Client side bridge, proxy, and PT support

Arti clients should be able to use outbound proxies, pluggable transports, and bridges.

To use proxies:

• Allow configuration of at least SOCKS4, SOCKS5, and SOCKS*-with-Tor extensions for outbound proxy types. HTTP is optional. (4h)
• Implement the above protocols. (16h)
• In the code, allow these proxies to be applied to a single TCP connection, or to all TCP connections. This might need to apply at the channel level; we'll probably need to add more complexity in tor_chanmgr. (16h)
• When these proxies are configured, apply them to all outgoing connections that they're configured for. (16h)

To implement bridge usage:

• Allow a configuration of a list of bridges. (8h)
• Allow bridge usage to be turned on and off. (4h)
  • Possibly, kill all streams and circuits when doing this. (24h)
• Support code, either in dirmgr or as a separate thing, to download and maintain a set of router descriptors for a set of configured bridges. (40h)
• Support multiple guard sets, and switching between them. (24h)
• Extend guard manager code to allow guards to be bridges as well as relays in the public network. (24h)
• Extend circuit manager code to use bridges correctly. (24h)
• (Also, see all places in the specs that talk about bridges)

To implement PT usage:

• Allow a set of pluggable transports to be configured, either as managed or unmanaged proxies. (12h)
• Allow bridges to be configured to use pluggable transports. (4h)
• For unmanaged PTs (are these used?), connect to chosen IP:Port and speak SOCKS. (defer)
• Implement the code to launch and manage a pluggable transport according to the protocols in pt-spec.txt (24h)
• For managed PTs, launch them when we need them, handle it if they crash, and route traffic through them via SOCKS as appropriate. If we go for a long time without using a managed PT, maybe shut it down. (40h)
• (Also, see pt-spec.txt)