don't start ClientTransportPlugin proxies until we have a bridge that wants them
Eventually we want to ship the standard Tor Browser Bundle with a set of supported client transports. We don't want to launch all of the possible transports when Tor starts, because most users won't ever configure a bridge line that asks for a given transport.
So the client managed transports should launch only when we are configured to use a bridge that needs them.
And maybe they could be closed after we no longer have any bridges that need them. That could certainly wait and be considered a "later feature" though.
Do we foresee any client transports that would want to start earlier than when a bridge shows up that wants to use them? I guess that ties into #5010 (moved).
Another option would be for Vidalia to paw through your bridge lines and know to setconf a given ClientTransportPlugin line when it sees a certain type of bridge line. Putting the smarts in Vidalia is probably a poor choice though.
[I'm not sure which component this should be in -- either a Tor one or the pluggable transport one. Picking the one Nick is more likely to see, for now.]
[I'm also not sure which milestone to use. We can push it back to 0.2.4 if it's too much like a feature. That would mean that our "normal clients using pluggable transports" bundles will want to use 0.2.4.]