See task 1114. The most plausible explanation for someone sending us weak
DH keys is that they experiment with their Tor code or implement a new Tor
client. Usually, we don't care about such events, especially not on warn
level. If we really care about someone not following the Tor protocol, we
can set ProtocolWarnings to 1.

One was a simple buffer overrun; the other was a high-speed pointer
collision.  Both were introduced by my microdescs branch.

The old flavored consensus URL format made it harder to decode URLs
based on their prefixes, and didn't take into account our "only give
it to me if it's signed by enough authorities" stuff.

The point of doing SHA256 twice is, generally, is to prevent message
extension attacks where an attacker who knows H(A) can calculate
H(A|B).  But for attaching a signature to a document, the attacker
already _knows_ A, so trying to keep them from calculating H(A|B) is
pointless.

This means we need to handle the existence of multiple flavors of signature
in a detached signatures document, generate them correctly, and so on.

This patch introduces a new type called document_signature_t to represent the
signature of a consensus document.  Now, each consensus document can have up
to one document signature per voter per digest algorithm.  Also, each
detached-signatures document can have up to one signature per <voter,
algorithm, flavor>.

The consensus documents are not signed properly, not served, and not
exchanged yet.

The original proposal was vague and would have made older Tors reject
detached-signature documents as soon as they saw one with flavors.

Previously, we insisted that a valid signature must be a signature of
the expected digest.  Now we accept anything that starts with the
expected digest.  This lets us include another digest later.

Conflicts:
	ChangeLog
	configure.in
	contrib/tor-mingw.nsi.in
	src/or/config.c
	src/win32/orconfig.h

backport of c43859c5
backport of 0d13e0ed

Partial backport of 381766ce.
Partial backport of 56c6d785.