Since bloom filters are probabilistic, it's nice to make it clear
that the "contains" operation can have false positives.

Now the address-set code and the digest-set code share the same
backend.

Closes ticket 26510

Fixed bug 26479.  Bug introduced by 0a6f4627; bug not in any
released version.

Fixes bug 26480; bug appeared when we re-enabled the geoip tests on
windows.  Bug originally introduced by our fix to 25787; bug not in
any released Tor.

This patch:
  - introduces an fdio module for low-level fd functions that don't
    need to log.
  - moves the responsibility for opening files outside of torlog.c,
    so it won't need to call tor_open_cloexec.

This change makes a whole bunch of things in torlog.c break, since
apparently I did not find all the fd dependencies.

The locking code gets its own module, since it's more fundamental
than the higher-level locking code.

Extracting the logging code was the whole point here. :)

Now that I know that "strings" nests below "container", I know this
is safe.

The other time stuff is higher-level

Containers were using crypto_digest.h, just to see the value of
DIGEST_LEN.  Moved those constants into a new defs module.