[#866] Generalize ceContracts to a function, add contract state getter to morley-client

I didn't add a way to "merge different contract sources" as the issue suggests, because given the signature it's rather trivial, and particulars should be decided by the consumer anyway. Adding functions nobody will ultimately use is rather pointless. As an example:

type ContractStateGetter m = ContractAddress -> m (Maybe ContractState)
mergeContractStateGetters :: Monad m => [ContractStateGetter m] -> ContractStateGetter m
mergeContractStateGetters = fmap (runMaybeT . asum) . traverse (fmap MaybeT)

See Test.Interpreter.NetworkContractResolver for an example implementation.

The issue also suggests working with testnets by passing chain id. Without a rather substantial change to morley-client that is currently impossible, as morley-client only works with the main chain, period. IIUC, which chain is the main chain is decided by the node. I suggest splitting this into a separate issue if it's actually required.

Description

Problem: in some contexts, we want something more flexible than just a Map for contract state, e.g. in debugger we may want to fetch contracts from the network on the fly.

Solution: Parametrize 'ContractEnv' by the runner monad, generalize ceContracts to ContractAddress -> m (Maybe ContractState).

One somewhat inconvenient side effect is we have to make EvalOp into a newtype to avoid infinite types (as RWS ends up parametrized by ContractEnv, which is parametrized by RWS etc ad infinitum). An argument could be made that a newtype is ultimately a cleaner option wrt InterpreterStateMonad instances anyway (f.ex. see Test.Interpreter.Annotations diff), despite some boilerplate.

Problem: we may want to get 'ContractState' for some contract from the network to feed it to our interpreter. Doing this, while already possible, is a bit awkward.

Solution: add a utility function to Morley.Client.RPC.Getters

Also a couple minor chores.

Related issue(s)

Resolves #866 (closed)

✅ Checklist for your Merge Request

Related changes (conditional)

• Tests (see short guidelines)

  • If I added new functionality, I added tests covering it.
  • If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.

• Documentation

  • I checked whether I should update the docs and did so if necessary:
    • Root README and other README.md files
    • Haddock
    • docs/
  • I updated changelog files of all affected packages released to Hackage if my changes are externally visible.

Stylistic guide (mandatory)

• My commits comply with the following policy.
• My code complies with the style guide.