Represent hash digests as byte-arrays

## Why

Right now, there are several parameters in class `mithril_common::entities::Certificate` that represent Sha256 digests and are stored as hex strings. For instance, the hash digest `7b8141c9642b573de4dda33455f9b4b7e8e782666a56e8cca42fa15279dabd90` consists of 32 bytes (the first one being `7b`, or `123` in decimal), but it is being stored as the String `"7b8141c9642b573de4dda33455f9b4b7e8e782666a56e8cca42fa15279dabd90"`, which is now taking 64 bytes to store, as it is a 64-sized String. The fist byte of this array now is `0x37`, (`55` in decimal) since it is the corresponding ASCII value to the char `'7'`.

This happens in parameters such as `hash`, `previous_hash`, or `signed_message`. Aside from any cryptographic vulnerability that may arise, it implies an overhead both in the storage of the certificate and in the computation of the hash of the certificate. This results in an even bigger burden when trying to include this computation in a SNARK, since it almost doubles the size of the trace required to generate proofs of validity of a Mithril certificate.

Classes of the parameters of the `Certificate` struct also have this problem. For instance, the method `compute_hash` of the class `mithril_common::entities::protocol_parameters::ProtocolParameters` returns a 64-length String representing the Sha256 digest, which ends up being fed into the method `compute_hash` of `mithril_common::entities::certificate_metadata::CertificateMetadata` as a 64-byte array instead of a 32-byte array. This again returns a 64-byte array that is fed into another hasher, and so on.

## What

This could be fixed by changing the type of these parameters to a class consisting of a fixed-length byte array, so that we avoid conversion when handling hash digests.