refactor: (De)Serialization of points using GroupEncoding

[huitseeker]

Context

In #30 and in #39 this repo implements the SerdeObject trait that allows straight-line serialization and de-serialization of the internal point representation. This practice makes a lot of sense when (de)serialization is used to do local caching in zk-algorithms, and some sense when performing absorptions into e.g. a transcript.

However, as a format of exchange it isn't compatible with classical point (de)serialization which more traditionally uses the compressed point representation, which is helpfully defined here (for all curves in this repo) as the implementation for the zkcrypto/group::GroupEncoding trait for both projective and affine point representations (and is also what pasta uses).

Precisely because the SerdeObject trait allows an alternate route to get the raw representation of point objects (and, IIUC, downstream repos use these code paths), the default implementation of the Serialize/Deserialize traits could hence aim at compatibility and use the traditional compressed point representation for serde, which is what this PR suggests.

In a nutshell:

• the SerdeObject code paths provide raw representation bytes,
• the Serde code paths provide the classical compressed point representations.

Alternative

Because the implementation is limited to one single point of indirection (the serde annotation on $name, $name_affine becomes one macro call), we can also envision more optionality by e.g. opening a feature (e.g. "compressed_serde") allowing the user to pick and choose what serde would give them.

In detail

• Updated curve point (de)serialization logic from the internal representation (generated by #[derive(Serialize, Deserialize)]) to the representation offered by the implementation of the GroupEncoding trait.

See also

#85

[CPerezz]

I like the direction this takes.
In any case, will ask the review of other team members to see their opinions.

I like that SerdeObject (which we could rename TBH) serves as raw/unchecked encoding and that then, regular serde is used for canonically checked en/decoding.
If we can also guarantee that with GroupEncoding we can both serialize and deserialize in compressed & uncompressed forms, that should be it.

[han0110]

LGTM!

[davidnevadoc]

I agree with the rationale of the solution proposed in the description. LGTM!