Add trace message codifier

[SeungheonOh]

Small utility function to turn long messages into code table.

[L-as]

My thoughts:

• I can't see why you want this TBF, when is this useful? You don't want strings on-chain anyway?
• If you did want error codes on-chain, wouldn't it make more sense to use a more compact representation that uses the full extent of UTF-8?
• Rather than doing this in a post-processing step, shouldn't ptrace etc. do this at generation time? You could add another alternative between the no tracing and full tracing options.

(Feel free to disregard of course, this isn't a "request change" review.)

[SeungheonOh]

This is per @bladyjoker 's request. I see this being very useful. IMO, not having any trace for mainnet script was a huge mistake, at least for Liqwid. Anytime script threw up, it was massive pain to recreate that with scripts with tracing to actually figure out what went wrong. Codifying error messages would save a lot of efforts without not much cost since it will be reference script anyways.

As for UTF-8 codes, I think that is a good idea. I change it to support UTF-8 tags.

Also, for having this on Plutarch's compile time, this was made to be external tool so that it can be used on already existing scripts as well. Also, deep integration to Plutarch was too much effort; this is small and portable. Maybe if we can get more funding on Plutarch, we can tackle this.

[L-as]

That makes more sense, but FWIW you should be able to just use the same inputs for the script to figure out why it failed.

[SeungheonOh]

Not really, in case of Liqwid, we'd need to deploy extra sets of scripts which will cost few hundred Ada and make changes to offchain in some annoying way. So, rather, we have this utility that extracts CBOR and input UTXOs in their resolved form into JSON. We import that to Haskell project and run the CEK manually. It is less painful for sure, but still immensely annoying. Not to mention, this is very offchain framework dependent.