Balance between memory and computation for commitments

[thomas-quadratic]

Commitments are needed to generate proofs, but they are also used recursively to compute commitments in parent nodes.
However, they are intrinsically elliptic curve points, and need conversion:

1. Commitment itself can be serialized to bytes and deserialized from bytes to communicate between Java and Rust. This is useful for proof generation, as the actual commitment has to be recovered.
2. Commitment needs to be converted to scalar field elements to be able to recursively commit them in a parent commitment. This operation is relatively expensive (division) and is not easily inverted (can't recover the commitment from the field element).

We could in principle store only the serialised version of the commitment in Java, and compute 2 when needed. Or we could store both.

We would need to strike a good balance between the two. Perhaps storing both commitment and hash (field element) only for the RootNode, and commitments only for the other nodes would be sufficient. This case would be good if we do not call commit too often (like once).