Support compressed and uncompressed point serialization

[dtebbs]

Allows compressed / uncompressed points to be used in different situations, independently of the build configuration.

[AntoineRondelet]

Why don't we check that the point is on the curve first?
Seems to me that the deserialization logic of a point in the affine space should be:

1. Recover x, y
2. Check that the tuple (x, y) is on the curve, i.e. satisfies the curve equation
3. Either do the "safe subgroup membership test" or mult by cofactor to make sure we have a point in G1 and not a point (which may be of low order) in the E/Fq group

Do I miss something? (Note: this code initially originates from the library, and has just been moved around in this PR - so this question applies to the current state of the library, as in master, for the deserialization of uncompressed points)

[AntoineRondelet]

Note, it seems to me that, the same assumption is made in the deserialization of compressed points, since I can read here that the sqrt function does not terminate if the element is a quadratic non-residue in the field: https://github.com/scipr-lab/libff/blob/master/libff/algebra/fields/fp.hpp#L108

We can "skip" the bullet 3. above here since cofactor = 1, but why skipping bullet 2.? I'd be in favor to test for quadratic residuity using Euler's criterion (and the euler exponent defined here: https://github.com/scipr-lab/libff/blob/master/libff/algebra/fields/fp.hpp#L54) first, and only proceed if the test is valid.

These functions act as I/O with the backend of the library, so I would be in favor to make no assumption about their input, and the parsed points.
As such, I would be in favor to add these checks. @dtebbs @madars @ValarDragon thoughts?
This is related to #50