add alternative Ed25519 switching

[mfourne]

As discussed with Mikhail last year on cabal-devel, I now would like to present a minimal patch to enable pure(r) Haskell cryptographic signatures. He expressed possible acceptance of a default-off compile-time option, which is herein included with minimal needed changes elsewhere. The new dependency provides almost the same API as the currently default ed25519 package, but uses another library underneath.
I have adressed some prior complaints to my optional dependency:
My library is now much smaller in dependency footprint. It is also undergoing academic review. Better documentation is still missing, though.

[Mikolaj]

@gbaz: would you perhaps be able to review this?

[Mikolaj]

@mfourne: how are you? how is the academic review going? I'd love to rescue this PR, but I'm completely alien to the topic. Could you provide any more documentation? Suggest a reviewer? E.g., is Mikhail on github?

[mfourne]

Hi, doing lots of work academically around this topic, currently building a verifier for binaries to check if the cryptographic code really fulfills the Constant Time formal security criterion, which I previously did by hand for my own code. One PhD student started working on adding refinement types to prove my code CT, but I don't know how far this progressed.
In general, I think it would be nice to switch away from embedded C code in the implementation of our cryptographic primitives and switch to (formally proven or provable) implementations. My code does not fulfill this at the moment, but I am exploring this and related topics in my research. Maybe via fiat-crypto writing low-level Haskell code, maybe via Jasmin, I can't finally say - this area is very active right now.
At the moment, my published code is not formally proven correct (but fulfills the KATs), not formally proven CT, not as fast and my documentation is still lacking (smallest hurdle, but still relevant).
I would be fine to include the option to switch implementations (the only thing this PR does) or let it rest until my own code is a general replacement and decide upon a way forward then.

[Mikolaj]

Thank you very much for the details. In that case, perhaps let's keep that PR open, as a sign that exciting things are brewing in this development and research domain. Keep at it! :)