Added cofactors to non-edwardian curve interfaces

[AntoineRondelet]

Proposal to address #45

Question: What is the security provided by the edward curve? It is documented that it provides 80 bits of security, but is that still the case today? Would there be a reason to remove this curve from the lib? (this is outside of the scope of this PR of course)

[AntoineRondelet]

@ValarDragon I changed the target branch back to master to keep the diffs of this PR clean (otherwise the diffs also contain some former commits etc which is more annoying to review).
I like the idea to merge to staging first though, and periodically merge staging to master to package new releases. Happy to go with this method if you are all happy with it.

Note: We'd need to update staging with master, as it does seem to be a few commits behind for now (we can just rebase it on top of master if necessary)

[ValarDragon]

This looks great to me! Sorry for the delayed review. I think its good to merge into staging, and then we can make a new release

These sage scripts will probably be very useful!

/cc @Pratyush would it be useful to have code to generate C++ and Rust curve code based off this type of sage file?

[ValarDragon]

I'm not sure what the edwards code is for, and 80 bits of security doesn't seem useful for anything anymore. Maybe the idea of this curve was to have an Edwards curve model, which can be constructed from the scalar field?

If so, we should probably deprecate the existing curve and demonstrate it on jub-jub. (And be sure to not have it implement the pairing interface)

[Pratyush]

I believe the special thing about these Edwards curves is that they’re pairing friendly

[ValarDragon]

Do you have any thoughts about whether pairing friendly edwards curves are useful/should be maintained? I don't know of anyone using it, nor do I know of a concrete reason to not use them for BLS.