Update tests to use tasty + nettest interface + batching

[gromakovsky]

Clarification and motivation

Our tests are somewhat messy and slow, we can clean them up to use latest cleveland features more efficiently.

Acceptance criteria

1. We don't use hspec and tasty-hspec to group tests, we group them using tasty directly.
2. stablecoin-nettest and stablecoin-test are merged into one test-suite. Previously we kept them separated to be able to run only non-network tests, but now it's possible in a united test suite as well.
3. We put operations into batches as much as possible to make tests (presumably) faster.
4. We don't use the Integrational interface directly unless it's really necessary (it shouldn't be, because the Nettest interface should contain all Integrational features).

[Martoon-00]

I highly do not recommend starting using batches before one issue about batching is implemented. The interface should change, hopefully, after that making a batch will be as simple as wrapping a code into batch call.

[pasqu4le]

I'll add this as a note here: there is a TODO in Lorentz.Contracts.Test.Permit about replacing the deprecated rewindTime in favor of advanceTime once the relative issue in morley is solved.

The issue has however since been closed in favor of adding it only to nettest, so as per the number 4 of this issue we should either remove that while migrating those tests to nettest or in case of necessity just remove the TODO (as the integrational-only advanceTime isn't coming anymore AFAIU).

[pasqu4le]

Note, for future reference: this is in large part solved by #187

It's possible however that there are some improvements left (particularly batching) so we'l need to check that.

[lierdakil]

There really isn't much potential for batching, except for the initial set-up/origination (and even there it's somewhat limited) In most cases, as things are stateful, either next operations depend on the result of the previous ones, operations from different senders need to be interleaved, or we're testing for errors in specific calls, neither of which allows for effective batching.