Exhaustively testing padding combinations is really slow, and was
causing timeouts during the Debian ARM package build process.  Attempt
to improve the situation by:

 * Reusing the client and server keypair for all of the tests, to cut
   runtime down by  ~50%.
 * Splitting the client side and server side tests up, as it appears
   the timeout is per-test case.

If this doesn't fix things, the next thing to try would be to reduce
the actual number of padding lengths tested, but that is a last resort
at the moment.

Instead of "node-id" and "public-key" that are Base16 encoded, use
"cert" which contains the "node-id" and "public-key" in Base64 encoded
form.  This is more compact and cuts the length down by 49 characters.

Write an example client bridge line suitable for use with the running
obfs4 server instance to "obfs4_bridgeline.txt" for the convenience of
bridge operators.

 * Unbreak inbound TYPE_PRNG_SEED processing.

 * IAT obfuscation is now a per-bridge argument (iat-mode).
   * 0 (default) = Disabled.
   * 1 = Enabled, ScrambleSuit-style with bulk throughput optimizations.
   * 2 = Paranoid, Each IAT write will send a length sampled from the
     length distribution. (EXPENSIVE).

The "iat-mode" argument is mandatory on the Bridge lines, and as a
ServerTransportOption.  Old statefiles will continue to load and use
the default value, edit it if your hat is made of tin foil.

WARNING: THIS BREAKS BACKWARD COMPATIBILITY.

This is primarily to work around bug #12930.  Base16 was chosen over
unpadded Base64 because the go runtime Base64 decoder does not handle
omitting the padding.

May $deity have mercy on anyone who needs to hand-enter an obfs4 bridge
line because I will not.

Changing from "drbgSeed" to "drbg-seed" to be consistent with the
ServerTransportOptions to allow for easier copy/paste.

Golang's command line parser is slightly cumbersome to use with
subcommands, so the arguments are "obfs4-iatObufscation" and
"obfs-distBias" instead of obfsproxy style subcommands.

 * Changed obfs4proxy to be more like obfsproxy in terms of design,
   including being an easy framework for developing new TCP/IP style
   pluggable transports.
 * Added support for also acting as an obfs2/obfs3 client or bridge
   as a transition measure (and because the code itself is trivial).
 * Massively cleaned up the obfs4 and related code to be easier to
   read, and more idiomatic Go-like in style.
 * To ease deployment, obfs4proxy will now autogenerate the node-id,
   curve25519 keypair, and drbg seed if none are specified, and save
   them to a JSON file in the pt_state directory (Fixes Tor bug #12605).