Rework `TxSkel` and `Constraints`

[carlhammann]

This is a draft for now; a real solution should at least close #173, #168, #165, #164, and #129.

[carlhammann]

This is now ready for a first round of comments. My stopping criterion was that the direct, Contract and Staged monads compile with the new TxSkel type. The two main design goals that led to its current form are as follows:

• The Eq instance should define a congruence on the Monoid of TxSkels.
• toLedgerConstraint should be injective.

Both of these assertions are tested with QuickCheck in Cooked.Tx.Constraints.TypeSpec, but the test of the second property has a stack overflow that I don't yet understand. If anyone can help me diagnose it, that would be much appreciated.

I would mostly like feedback on conceptual content of the module Coocked.Tx.Constraints.Type, since that's where the meat is. If you have remarks on the other changes, they're welcome as well.

[carlhammann]

Here are some unordered thoughts for next steps:

• Testing that toLedgerConstraint :: TxSkel -> LedgerConstraint Void is injective is good, but testing that runMockChain . generateTx' :: TxSkel -> Either MockChainError (([Pl.PaymentPubKeyHash], Pl.Tx), UtxoState) returns different transactions for different TxSkels would be even better. The problem with this approach is that the generators I have written so far generate TxSkels that pass the latter function (in the sense that it does not return a MockChainError) with a very low probability, so that QuickCheck just gives up after discarding almost all tests (more than 99% of them, on most runs).
  • In general, I think it would be useful to have some generators for TxSkels with certain properties, both to write tests for cooked and to write "fuzz" tests for contracts. That could also be an interesting source of Tweaks.
• On the whole, I do not yet trust the coverage of the tests. The average random pair of TxSkels is very different, so it's not surprising that the corresponding LedgerConstraints are different. We should test a few examples of only slightly different TxSkels.
• Would it maybe make sense to define the Eq and Ord instances for TxSkel and friends along the lines of

  instance Ord TxSkel where 
   compare = someSuitableCompare `on` toLedgerConstraint @_ @Void 

  thus making toLedgerConstraint injective by definition?

• What about surjectivity? How to test that all transactions can be described by our TxSkels? Almost certainly, we won't be able to generate all transactions in the sense of ==, since the representations used by plutus-apps have lists in places where sets are the actual meaning, but how do we test that we can hit one member of each "equivalence class for transaction validation"? (How to even make this notion precise?)
• Should the collateral inputs become an extra field on the TxSkel? This would be truer to the idea that transaction skeletons are "transactions with holes", and that the holes are filled at transaction generation time. The role of the _txSkelOpts should in my opinion be to control transaction generation, and it seems strange to me that the collateral "hole" should be part of them.
• Thinking of issue #180: At the moment the _txSkelRequiredSigners are translated into MustBeSignedBy constraints by the toLedgerConstraint translation. Additional signers derived from the MockChainEnv are added later in the transaction generation process. I'm not yet sure I've understood all of the subtleties involved, and consequently I'm not sure what information is needed on the TxSkel.