Tx simulate plutus v3

[KtorZ]

• 📍 Move script context e2e tests under a nested 'v2' directory.
  And rework scripts to run them in anticipation of new v3 contexts.

• 📍 Upgrade pallas to v0.0.29, and start support for simulating transactions carrying Plutus v3 scripts.

• 📍 Further remove todos for v3, and reduce duplication in transaction evaluation

• 📍 Fix Plutus v3 validator hash calculation in blueprint.

• 📍 Actually decode Conway transaction in 'aiken tx simulate'

• 📍 implement a strict subset of PlutusV3 transaction info
  More specifically, that is simply mimicking the script context from
  v2, minus the new governance features.

• 📍 define UPLC machine default cost models for Plutus V3.

• 📍 Fix ToPlutusData serializer for V3
  This is intense, as we still want to preserve the serializer for V1 &
  V2, and I've tried as much as possible to avoid polluting the
  application layer with many enum types such as:

  pub enum TxOut {
    V1(TransactionOutput),
    V2(TransactionOutput),
    V3(TransactionOutput),
  }
  

  Those types make working with the script context cumbersome, and are
  only truly required to provide different serialisation strategies. So
  instead, we keep one top-level TxInfo V1/V2/V3 type, and we ensure
  to pass serialization strategies as type wrappers.

  This way, the strategy propagates through the structure up until it's
  eliminated when it reaches the relevant types.

  All-in-all, this strikes a correct balance between maintainability and
  repetition; and it makes it possible to define different but mostly
  identical encoders for the various versions.

  With it, I've been able to successfully encode a V3 script context and
  match it against one produced using the Haskell libraries. More to
  come.

• 📍 Write down first e2e script context test for v3.

• 📍 Rename function variable in parser
  Better reflect its actual semantic. The name probably slipped through a wrong copy pasting.

• 📍 Improve / fix machine and uplc error reporting.

• 📍 Support multi-validator in script context accept test.

• 📍 test 'mint' purpose and script context creation.
  Alongside a bunch of other stuff from the coverage list. In
  particular, the mint transaction contains:

  • reference inputs
  • multiple outputs, with assets, and type-0, type-1 and type-6
    addresses.
  • an output with a datum hash
  • an output with an inline script
  • carries an extra datum witness, preimage of the embedded hash
  • mint, with 2 policies purposely ordered wrongly, with 1 and 2
    assets purposely ordered wrong. One of the mint is actually a
    burn (i.e. negative quantity)