If a bridge supports obfs4, don't give out its other flavors

There's a FOCI 2018 paper looking at blocking of bridges inside China, and one of their conclusions is that China has moved from "block by IP:port" to "block to IP": https://www.usenix.org/conference/foci18/presentation/dunna

If that is so, it means that when bridgedb gives out the vanilla ORPort of an obfs4 bridge, then some user will get it, try to use it from inside China, trigger the active probing, and get the whole IP address blocked -- including the obfs4 port.

The fix: when bridgedb gets a bridge that supports an active-probing resistant transport (right now that means obfs4), it needs to decide not to give out the other transports for that bridge (vanilla ORPort, obfs3, etc).

(There are two caveats for this plan. First, it means we're prioritizing obfs4 bridges for the China context, since all of these transports will still be useful for countries other than China. I'm ok with that. Second, it assumes that the FOCI paper is actually correct in its conclusions about how China has changed its blocking. I recall in the Q&A at the end of the presentation that some folks questioned the analysis, but I didn't follow it enough to form a solid opinion. But even if China isn't doing its censorship in this new way yet, now is a great time for bridgedb to become able to handle it.)