Fix curves interfaces inconsistencies

[AntoineRondelet]

On the current master branch, the interfaces of the various curves are not consistent.
This is problematic as we cannot write code that would work for all curves and be generic.

This issue has to deal with how coordinates are managed in all curves implementations.
There are 5 curves implementations:

• alt_bn128
• bn128
• mnt4 and 6
• edwards

All these implementations follow different approaches to represent and access the points coordinates:

• alt_bn128: Point coordinates are public attributes X, Y, Z (see: https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/alt_bn128/alt_bn128_g1.hpp#L35)
• bn128: Point coordinates are stored in a public attribute coord which is an array of 3 elements (see: https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/bn128/bn128_g1.hpp#L36)
• edwards: Point coordinates are public attributes X, Y, Z (see: https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/edwards/edwards_g1.hpp#L32)
• mnt4/6: Point coordinates are private attributes X_, Y_, Z_, with getters X(), Y(), Z() (see: https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/mnt/mnt4/mnt4_g1.hpp#L49-L51 and https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/mnt/mnt4/mnt4_g1.hpp#L27-L28)

(Note that the comment above only links to the groups G1, but the same applies for the G2 groups).

As such, we see that there are 3 different methods used to handle the point coordinates.
This is problematic since we cannot easily switch "one curve for another" and write generic code.

An example of affected project is: https://github.com/clearmatics/zeth, especially the functions here: https://github.com/clearmatics/zeth/pull/181/files

This PR fixes the above issue by refactoring the groups interfaces consistently. The convention followed is the one of the alt_bn128 and edwards curves where the point coordinates are public attributes called X, Y, Z.

Important note1: This is a breaking change.
Important note2: I haven't ran benchmarks for this change. I suspect that the bn128 arithmetic may be a tiny bit affected by the changes as we need to pay the cost of filling the coordinate arrays before calling the functions from the namespace bn::ecop. This should be negligible compared to the actual "curve arithmetic" though.