IF: Ensure all serialization of g1/g2 uses serialization form

[arhag]

Serialization form is defined to be:

1. Non-Montgomery form and little-endian encoding for the field elements.
2. Affine form for the group element (the z component is 1 and not included in the serialization).
3. Binary serialization encodes x component first followed by y component.

All network messages that use the serialized form of g1/g2.
All files written to disk should used the serialized form of g1/g2.
Logs will need to use the base64url encoding of the serialized form of the g1/g2 logged.

The bls_public_key and bls_signature should be updated to store the binary data for the serialized form. That way pack and unpack can automatically serialize the data in the correct form. When constructing a bls_public_key (or bls_signature) either using a constructor that takes g1 (or g2) or when unpacking (in which case this code should be in reflector_init), the class must validate the serialized data and construct the g1 (or g2) as a cached private field in the class. That g1 (or g2) should be in Montgomery Jacobian little-endian form so that it can be used efficiently in BLS math.

Keeping the serialized data in bls_public_key and bls_signature allows for quickly writing out the serialized form when needed, e.g. in a vote message or in a QC attached to the block, and it also allows for relatively fast conversion to the base64url encoding for logging purposes.

There are some places in ephemeral memory where it makes sense to store the g1 (or g2) directly rather than store bls_public_key (or bls_signature).

One case is when a temporary value is being mutated in a function for some use in the function to then be thrown away. For example, computing the g1 aggregation of the public keys of the finalizers who are indicated as participating in a QC which is used to validate the aggregated g2 signature. In that case, the g2 can be pulled from the cache of the bls_signature recovered from the valid QC attached to the block. But there is no need to build up a bls_public_key as the accumulator when aggregating over the participating finalizers since that would require converting to serialized form for each addition, which is expensive.

Another case is when storing the aggregated signature g2 in the pending QC within a block_state. For similar reasons as above, it is more efficient to store this as a raw g2 rather than as a bls_signature. However, when choosing the best QC to include in a new block that is pulled from the pending QC, that accumulating raw g2 must first be used to construct a bls_signature and store that as the valid QC in the block_state. Then that constructed bls_signature, which already has the serialized form within it, can be used to quickly create the QC that is attached to the block in a block extension.