Better (de)serialization

[gshen42]

We need a better (de)serialization method than Show and Read. Some questions to consider:

• What format to use? (Plain String? JSON? CBOR?)
• Use an existing library or write our own?
• How do we support different (de)serialization methods for different backends? (a local backend that uses MVars to communicate might not even need (de)serialization.)
• Can we support user-customizable (de)serialization methods?

[Qqwy]

One interesting possibility might be Data.Compact, though giving users the option to customize this would also be nice.

[plredmond]

I think a design that leaves the door open to arbitrary user-provided solutions would be

1. HasChor defines a typeclass to serialise and deserialise via some chosen wire format type (probably LazyByteString)
2. HasChor's ChoreoSig requires that typeclass on the relevant constructors, and wrapper functions (eg. Cond and cond)
3. HasChor's built-in backends (eg Choreography.Network.Http) perform serialization and deserialization using that typeclass

This allows a user of HasChor to implement the typeclass with Show/Read or Serialise (addressing point 1 above with "don't choose", point 2 above with "don't implement", and point 4 above with "yes").

Point 3 is more complex, and I think, doesn't justify the complexity it requires to solve.

For point 3, above, you'd probably want the MVar to not contain data serialized to LazyByteString. To approach a solution here, the HasChor typeclass I recommended might serialize to/from an associated type family, allowing an implementor of it to write an instance like

instance HasChorSerialise UserDatatype where
    type WireFmt UserDatatype = UserDatatype // don't serialize
    toWireFmt = ...
    fromWireFmt = ...