In addition, there were numerous elements of inline CSS styling and
various onclick handlers which had to be rewritten.  While I was at it,
I rewrote the stylesheets to fix serious usability/readability problems,
particularly when using mobile devices like tablets and phones.  Other
problems, like the onion logo in the background sometime overwriting or
blending with text on some pages, are now fixed as well.

 * ADDS a new class, `bridgedb.https.server.CSPResource`, which handles
   adding an appropriate CSP header to all pages which inherit from it.
 * FIXES #15968: https://bugs.torproject.org/15968

 * CHANGES the CSS styling for some pages, for some window sizes and
   devices, to be more responsive, readable, and usable.
 * ADD @media CSS queries in order to improve readability and usability on
   small devices.
 * CHANGES the captcha.html page with various visual (i.e. the functionality
   hasn't been altered) improvements.
 * CHANGES the behaviour for loading additional CSS when rendered in a
   left-to-right charset.
 * CHANGE javascript functions to update the "aria-hidden" attribute for
   the QRCode modal properly, in order to improve accessibility
   (particularly for screen reader devices).
 * ADD use of "aria-disabled" attribute, for the "Select All" button
   when JS is disabled, for the accessibility reasons ibid.
 * FIXES #16649: https://bugs.torproject.org/16649

This allows for more accurate (but still mocked) testing of anything
that has conditional treatment of implementers/providers of IBridge.

 * CHANGE bridgedb.test.util.DummyBridge and DummyMaliciousBridge to declare
   that they both implement the IBridge interface.

Conflicts:
	lib/bridgedb/test/util.py

 * ADD bridgedb.bridges.IBridge interface specification.
 * CHANGE the following classes to declare that they implement the IBridge
   interface:
       - bridgedb.bridges.BridgeAddressBase
       - bridgedb.bridges.PluggableTransport
       - bridgedb.bridges.BridgeBase
       - bridgedb.bridges.BridgeBackwardsCompatibility
       - bridgedb.bridges.Bridge

Conflicts:
	lib/bridgedb/bridges.py

Because it seems awkward to require doing type checks in order to know
which port a bridge-like thing is listening on.

That is, previously, we could access PluggableTransport.port and
Bridge.orPort, but *not* Bridge.port.  Moving the port @property from
the PluggableTransport class to the BridgeAddressBase class (and
updating the Bridge.orPort @property to point at the port @property)
allows us to access the port property of either one without caring which
type it is.

In addition to allowing us to forego type checks, this allow allows us to
define an interface which essentially says that "a bridge-like thing is a
thing which has a fingerprint, address, and a port", which again allows us to
generalise code to deal with "bridge-like" things, rather than dealing with a
tuple of classes which happen to be considered "bridge-like" at the time of
writing.

 * MOVE the port @property from the PluggableTransport class to the
   BridgeAddressBase class.

 * CHANGE the Bridge.orPort @property to point at the new port
   @property.

Passing an integer around both requires less memory, and makes the IP
version filters in bridgedb.filters run faster (since they no longer
need to use isinstance()).

 * CHANGE bridgedb.bridges.Bridge to use ipVersion when working with
   BridgeRequestBase.

 * FIXES part of #12506: https://bugs.torproject.org/12506

 * ADD Filters.filterBridgesByUnblockedTransport().
 * CHANGE bridgerequest.BridgeRequestBase.generateFilters() to handle
   requests for unblocked bridges with pluggable transports.

This ensures that it's always lowercased when set, removing the need for
so many lower() calls.

 * CHANGE bridgedb.Filters.filterAssignBridgesToRing() to rename
   generated filter functions to include the subring number and the
   total number of subrings, e.g.
     filter.__name__ = "filterAssignBridgesToRing3of4"

 * CHANGE bridgedb.Bridges.FilteredBridgeSplitter.addRing() to name
   subrings based on their number.  For example, if an HTTPSDistributor
   has 3 total subrings and subring 3/3 is for known-proxy users, then
   the subrings would be named like:
     - HTTPS-IP4-1of3
     - HTTPS-IP4-2of3
     - HTTPS-IP4-Proxy
     - HTTPS-IP6-1of3
     - HTTPS-IP6-2of3
     - HTTPS-IP6-Proxy

Logging str(bridge) will produce a hashed fingerprint if safelogging is
enabled, so there's no use in calling logSafely(bridge.fingerprint).

The functionality tested in testDistWithFilterBlockedCountries() is now
tested in test_Dist.test_HTTPSDistributor_with_blocked_bridges() and
test_Dist.test_HTTPSDistributor_with_some_blocked_bridges().

These methods were never used.  Hashrings dump the bridges assigned to
them.

It wasn't a real metaclass, base class, or interface; its methods were
never used; it didn't provide any decent documentation; not everything
which inherited from it used its methods; nothing called super() for it,
or otherwise called methods on it.  Totally useless.

 * REMOVE bridgedb.Bridges.BridgeHolder class.
 * CHANGE everything which previously inherited from BridgeHolder to
   simply inherit from object instead.

 * ADD distribute.IDistibute interface.
 * ADD distribute.Distributor class, an implementation of IDistribute.
 * REMOVE bridgedb.Dist.Distributor.
 * RENAME HTTPSDistributor.getBridgesForIP() →
                                    HTTPSDistributor.getBridges().
 * RENAME EmailBasedDistributor.getBridgesForEmail() →
                                    EmailBasedDistributor.getBridges().
 * FIXES part of #12506: https://bugs.torproject.org/12506
 * FIXES part of #12029: https://bugs.torproject.org/12029

It was meant to be a method; it operates on the length of the primary
hashring of a Distributor.  Having it outside of the class that it
interacts with is just wacky.

 * CHANGE getNumBridgesPerAnswer into a method for the Distributor
   class.
 * CHANGE the unittests for the function to take this into account.