Show instance for UtxoState

[gabrielhdt]

This PR introduces a Show instance for UtxoState, and is related to #266.

I'm not sure where to put the instance declaration: either I put it next to the definition of UtxoState, but it makes a cyclic dependency graph, or I put it next to the definition of prettyUtxoState, and it feels kind of lost.

[florentc]

Check #265 for insight on the dependency cycle issue.

I am not in favor of re-introducing a Show instance for UtxoState that is based on PrettyCooked. See my opinion on issue #266

[gabrielhdt]

Would you prefer, or agree with a standard deriving? Or a slightly arranged deriving?

[florentc]

I think it is ultimately not a good idea to derive a Show instance because it makes it compulsory to provide a Show instance for datums. This is currently the case, datums are required to have a Show instance. But since the move to Pretty/PrettyCooked, datums are required to instantiate PrettyCooked and the Show constraint has become redundant (and the idea is to eventually remove it). I think the better approach is to solve #234 and provide convenient functions to use in the REPL that rely on prettyCookedOpt instead of show.

[0xd34df00d]

One opinion I've seen elsewhere is that, in the presence of pretty-printing for a family of types, Show is largely needed only as "inverse" to Read, which we don't provide and don't need really.

So, depending on what the rest of the folks think, I'm also totally fine with just not having any Show UtxoState at all, and relying on pretty -printing explicitly.

[gabrielhdt]

After discussion, the modifications brought in this pull request do not fit with the intended design.