Added a loading configuration file on the server side. The format is identical to the client configuration file except ClientTransportationPlugin is ServerTransportationPlugin. Uses go-shellwords to parse the config files.

Adds launching multiple chains. Now after finding the needed chains, all the pts needed by the chains are launched first. Then after each pt succeeds, if a chain has all its pts setup, it will launch.

the tor_pt_state_location env var now has '/fog' to it to avoid clobbering similar transports launched directly by tor instead of fog. See ticket #12613

Switched the obfs3_flashproxy into a config file. This file is now read as the default configuration if no configuration file is specified on the command line

- we actually want the second shim to listen on the callback port, not the first shim
- tor socks-connects directly to the first PT, it doesn't need a tcp-to-socks shim

Modified pt_launch_pair into pt_launch_chain. The new method of chaining starts with the last socks server pointing to the last pt with the destination being the bridge server. Then the middle pts are chained in reverse order. Finally the first socks server is started at the callback port and links to the second pt. The helper function pt_setup_socks_proxy takes care of setting up a specific SOCKS server.

Added a configuration class which reads in a fog-file. Added example fog-file. Added launching from a fog-file.

obfsproxy doesn't handle an empty value for this variable:
ENV-ERROR error parsing env-var: TOR_PT_SERVER_TRANSPORT_OPTIONS: Invalid options string ()

It's reading from a static list of method names and commands.

This doesn't change behavior, because websocket-server ignores an absent
environment variable. But this makes it match the setup for obfsproxy,
which insists on having the variable set.

- works around py2exe on wine silently not finding them

As with the client side, this looks like a mechanical transformation of
"obfs3|websocket" to "obfs3_websocket".

The situations with and without the obfs3 layer are parallel.
Without:
	client: flashproxy
	server: websocket
With:
	client: obfs3_flashproxy
	server: obfs3_websocket

"flashproxy" is one of the names recognized by flashproxy-client. The
other is "websocket". Since method names aren't allowed to contain a '|'
(#9580), this at least looks like a mechanical conversion from
obfs3|flashproxy to obfs3_flashproxy.

The transport list that you register with; i.e. the --transport option
to flashproxy-client and friends, is still "obfs3|websocket". That's
because the facilitator actually parses this string, and proxies use the
last part to decide how they will connect to you.