This is a big-ish patch, but it's very straightforward.  Under this
clang warning, we're not actually allowed to have a global variable
without a previous extern declaration for it.  The cases where we
violated this rule fall into three roughly equal groups:
  * Stuff that should have been static.
  * Stuff that was global but where the extern was local to some
    other C file.
  * Stuff that was only global when built for the unit tests, that
    needed a conditional extern in the headers.

The first two were IMO genuine problems; the last is a wart of how
we build tests.

This gives more accurate results under Clang, which can only help us
detect more warnings in more places.

Fixes bug 19216; bugfix on 0.2.0.1-alpha

IMO it's fine for us to make exceptions to this rule in the unit
tests, but not in the code at large.

This warning triggers on silently promoting a float to a double.  In
our code, it's just a sign that somebody used a float by mistake,
since we always prefer double.

This caught quite a few minor issues in our unit tests and elsewhere
in our code.

This caused a trivial warning in curve25519-donna-64bit.h, which
had two unused constants.  I commented them out.

This warning, IIUC, means that the compiler doesn't like it when it
sees a NULL check _after_ we've already dereferenced the
variable. In such cases, it considers itself free to eliminate the
NULL check.

There are a couple of tricky cases:

One was the case related to the fact that tor_addr_to_in6() can
return NULL if it gets a non-AF_INET6 address.  The fix was to
create a variant which asserts on the address type, and never
returns NULL.

Coverity noticed that we check tor_sscanf's return value everywhere
else.

Previously, we used !directory_fetches_from_authorities() to predict
that we would tunnel connections.  But the rules have changed
somewhat over the course of 0.2.8

Fixes the 0.2.9 instance of bug #19213, which prevented mingw64 from
working.  This case wasn't in any released Tor.

Fixes the 0.2.7 case of bug #19213, which prevented mingw64 from
working.

So, back long ago, XXX012 meant, "before Tor 0.1.2 is released, we
had better revisit this comment and fix it!"

But we have a huge pile of such comments accumulated for a large
number of released versions!  Not cool.

So, here's what I tried to do:

  * 0.2.9 and 0.2.8 are retained, since those are not yet released.

  * XXX+ or XXX++ or XXX++++ or whatever means, "This one looks
    quite important!"

  * The others, after one-by-one examination, are downgraded to
    plain old XXX.  Which doesn't mean they aren't a problem -- just
    that they cannot possibly be a release-blocking problem.

They apply to ancient GCC versions and to an unknown set of
configuration options. Notabug.

There was a > that should have been an ==, and a missing !.  These
together prevented us from issuing a warning in the case that a
nickname matched an Unnamed node only.

Fixes bug 19203; bugfix on 0.2.3.1-alpha.