Figure out what we can do with a custom binary format of our own

- Can we get smaller representations of things?

- Can we go faster?

- Can we give better errors?

Notes (from @kwxm ):
flat actually seems to do quite a good job, and it looks as if the author’s put a lot of work into parsing bits efficiently; can we just make a fork of that? I suspect there might be scope for speeding it up using Kmett-type techniques for example. I think it might also be possible to make its Plutus encoding a little more compact by using some specialised variable-length encoding for our constructors (like a Huffman code based on observed frequencies of constructors): there are tables in the cost model document that show that var, lam , and apply each account for about 28% of the constructors in our validation scripts, so if we could save one bit for each of these it might save a worthwhile amount of space. I also wonder about the efficiency of the zigzag encoding for integers, which requires some bit-shifting and arithmetic computations during decoding. If we were to analyse some scripts we might find that most of the numbers occurring in practice are positive, or are fairly small, and if something like that was the case then it might be worth coming up with a more efficient encoding (possible in addition to the existing one).