Clarify which bridges are used and which ones are skipped

If we receive a descriptor for a bridge which was not listed in the
network status, then we should not use it. We do not use it, but
this is not obvious without some investigation. Make this obvious.
Minor grammatical and clarifying corrections
We now support extra-info documents and pluggable transports

BridgeDB supports parsing extra-info documents which allows it to
retrieve information regarding the pluggable transports a bridge
accepts.
We use the "a" line of a bridge from the NS for its OR Address

The "a" line in the network status is checked and signed by the
bridge authority, so we prefer this over the "or-address" line in
the bridge descriptor.
Clarify how we parse bridge descriptors

Bring the description inline with how the the implementation
handles the descriptors and bridges.
Reword and improve description of the distributor
Improve description of IP-based distributor

We now use a CAPTCHA to weed out (most) scrapers. Also, improve
description of how bridges are selected based on filters and rings.
Describe how we decide the number of bridges we will return
We can sign all outgoing emails now
Attempt to answer some old questions, ask a new one.
Add description about how we display bridge addresses
Update spec: We also parse the "published" line.
Update spec: PT args are comma-separated.
Move specs and proposals into doc/ directory.
Merge branch 'fix/1606-based-on_bug1606_spec_update_rebased_r1' into develop