Refactor Plutus interface

[Soupstraw]

Currently some functions have constraints for both PlutusV1 and PlutusV2. I think these constraints can be removed when we make transScriptPurpose a class method.

[Soupstraw]

I tried to do some refactoring, but it looks like this is a lot of work. My idea was to create closed type families from Language to Plutus types. That way we can get a closed world on all Plutus types and that should make it easier to write and reuse functions that deal with Plutus. We'll also want to have the EraPlutusContext typeclass that takes both a Plutus version and an era as its parameters. This should allow us to easily map types from that era to the Plutus types each supported Plutus version (types such as DCert and ScriptPurpose).

The function that caused the most problems with this approach was collectTwoPhaseScriptInputs in Cardano.Ledger.Alonzo.PlutusScriptApi. The core of the problem was that the function outputs a list that contains a monomorphic Language type. We want this function to work on both Plutus V1 and V2 scripts. In that function we have to call the txInfo method, which is supposed to return a TxInfo corresponding to the language version we're interested in. However, since the language value that we have to match on is monomorphic, we don't learn the actual type of TxInfo.

I think we'll have to revisit the return type of collectTwoPhaseScriptInputs and consider using existential types to address these issues. This would probably mean a lot of changes in the codebase, but the result will be more type safe.

[lehins]

Fixed in #3899