Add the ed25519 ref10 code verbatim from supercop-20140622

We might use libsodium or ed25519-donna later on, but for now, let's
see whether this is fast enough.  We should use it in all cases when
performance doesn't matter.
Integrate ed25519_ref10 into our build system.
Add some explicit casts as needed to make ed25519_ref10 compile

Apparently, ref10 likes implicit conversions from int64 to int32 more
than our warnings do.
Add headers as needed to make ed25519_ref10 compile.
ed25519_ref10: use uint64_t and int64_t, not long long
Add Ed25519 support, wrappers, and tests.

Taken from earlier ed25519 branch based on floodyberry's
ed25519-donna.  Tweaked so that it applies to ref10 instead.
Tweak ref10 keygen APIs to be more sane.
Tweak ed25519 ref10 signing interface to use less space.

Unit tests still pass.
Fix API for ed25519_ref10_open()

This is another case where DJB likes sticking the whole signature
prepended to the message, and I don't think that's the hottest idea.

The unit tests still pass.
Another ed25519 tweak: store secret keys in expanded format

This will be needed/helpful for the key blinding of prop224, I
believe.
Restore the operation of extra_strong in ed25519_secret_key_generate
Add encode/decode functions for ed25519 public keys
Support for writing ed25519 public/private components to disk.

This refactors the "== type:tag ==" code from crypto_curve25519.c
Add curve25519->ed25519 key conversion per proposal 228

For proposal 228, we need to cross-certify our identity with our
curve25519 key, so that we can prove at descriptor-generation time
that we own that key.  But how can we sign something with a key that
is only for doing Diffie-Hellman?  By converting it to the
corresponding ed25519 point.

See the ALL-CAPS warning in the documentation.  According to djb
(IIUC), it is safe to use these keys in the ways that ntor and prop228
are using them, but it might not be safe if we start providing crazy
oracle access.

(Unit tests included.  What kind of a monster do you take me for?)
Draft implementation for ed25519 key blinding, as in prop224

This implementation allows somebody to add a blinding factor to a
secret key, and a corresponding blinding factor to the public key.

Robert Ransom came up with this idea, I believe.  Nick Hopper proved a
scheme like this secure.  The bugs are my own.
Fix linux compilation of ed25519_ref10

Our integer-definition headers apparently suck in a definition for
select(2), which interferes with the select() in ge_scalarmult_base.c
More documentation for ed25519 stuff.
Add the pure-python ed25519 implementation, for testing.
Add a reference implementation of our ed25519 modifications

Also, use it to generate test vectors, and add those test vectors
to test_crypto.c

This is based on ed25519.py from the ed25519 webpage; the kludgy hacks
are my own.
Cut the time to run the python ed25519 tests by a factor of ~6

I know it's pointless to optimize them, but I just can't let them
spend all that time in expmod() when native python pow() does the same
thing.