Pluggable Transports: Improve method of transferring parameters to client-side transports

Currently, client-side pluggable transports (like scramblesuit) that need parameters (like shared-secrets, etc.) are supposed to get them through the SOCKS protocol. Specifically, Tor is supposed to shove the shared-secret in the username/password fields of the SOCKS handshake.

Apart from the solution being ugly and super hacky it also imposes a size limit to our parameters, since SOCKS5 has a maximum length of 512 bytes of username/password (legacy/trac#9163 (moved)). SOCKS5 is needed since it's the only SOCKS version that officially supports IPv6.

As a more permanent solution than legacy/trac#9163 (moved) we should think of how to improve this situation. At least three ways come in mind:

a) We use the reserved METHOD field of the SOCKS protocol to define our own authentication method (see section 3 of http://csocks.altervista.org/rfc/rfc1928.txt). Then we use this new authentication method to pass parameters to pluggable transports.

This seems cleaner than before, but we still piggyback on the authentication mechanism (which means that if we ever wanted to password protect obfsproxy's SOCKS listener we can't) so it's not perfect. Also many libraries might not support reserved authentication methods, which means that some monkey patching will be needed.

b) We design and specify our own SOCKS protocol. SOCKS kinda sucks for PTs anyway (legacy/trac#7153 (moved)). I don't like this idea, because I don't like homebrewed protocols and it will require significant specification/development efforts to replace all the current uses of SOCKS in PTs.

c) We write yet another metadata protocol that happens after SOCKS but before application-layer data is transferred to obfsproxy. It's the equivalent of Extended ORPort for the client-side, and it might be useful for other information apart from client-side parameters. I don't like this solution either.

d) We define an environment varialbe similar to TOR_PT_SERVER_TRANSPORT_OPTIONS but for the client-side. Unfortunately, the client-side parameters are dynamic (parameters are different for different destination addresses) so the environment variable will also need to include the destination bridge address along with the parameter. Furthermore, if we ever wanted to make parameters completely dynamic (so that they change after Tor startup) this solution might complicate matters. Still this is not terribly bad (since we already parse env vars and we already do something similar on the server side), but it's not good either.