[#403] Add applicative-based batching interface to nettest

Description

This provides an interface for batched operations looking as follows:

inBatch $ do
  addr <- originate ...
  transfer addr ...
  return addr

instead of dedicated transferBatch and callBatch methods that accept a list with transfer parameters.

This looks good because

• Wrapping an existing set of operations into a batch is now very easy;
• Fewer nettest methods to keep in mind;
• Now it is possible to do multiple originations and transfers within a batch (not sure how useful it is in practice though). And that is without any overhead for the interface.

I add batching capabilities with this interface both to morley-client and nettest, however in the former case I provided only the most basic primitives; if someone cares, he can improve this situation later.

Some notes

Callstacks

Unfortunately, in case of failure, I cannot point to a specific transfer or origination that caused it, rather only to the entire batch. And this seems to be a fundamental batches limitation since larger batches will become harder to debug and test. As far as I can see, RPC response does not produce any hints on which exact operation has failed (see one and two for examples); maybe it's worth creating an issue in Tezos repo for that.

Tricky ApplicativeDo

Writing do-blocks in an Applicative may turn to be a nice quest, as e.g. this won't work, asking for Monad:

inBatch do
  transfer ...
  transfer ...
  -- but works with
  -- return ()

neither will this

inBatch do
  contract <- originate ...
  let a = ...
  return (contract, a)

So ApplicativeDo does not handle non-trivial cases. When this happens, I raise an error message mentioning common caveats and solutions, but the experience is still far from the best.

As I believe, this is still better than the old approach, because all the old cases can be expressed in the new interface without do-blocks with just the use of for and traverse - they work smoothly, and do not require dedicated *Batch methods with their own datatypes per method used as parameters.

Maybe we can consider alternative solutions here, though I don't see any solution that would supersede the applicative approach yet.

Related issue(s)

Resolves #403 (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.