Consistent test framework

[lsqrl]

Various tests should be set up to have a full coverage on all possible cases and at the same time be able to add new services easily and safely.
I suggest to use the following list in this order when a new service is added. The various tests should be written in a modular and re-usable way, so that the work to do when adding new services is minimal.

1. Integration tests. The goal is to ensure that all the implemented functions work, the addresses are properly set, the interfaces follow the correct ABI, and in general that the open-close-quote flow gives the expected result. They should include basic checks on when the external contract reverts (e.g. insufficient liquidity in or out, tokens in the wrong order, encoding done differently, etc...), but only to ensure the flow is executed entirely.
2. Target protocol tests. The goal is to ensure the service reacts to changes in the target protocol in a predictable way. Using one or more whales, we force them to perform fuzzy tasks in a randomized order, and inserting the open-close-quote flow between them. As an example, considering functions f1 and f2 changing the state of the target protocol, we may
   f1 -> f2 -> open -> f1 -> f2 -> close
   f1 -> open -> f2 -> f2 -> f1 -> close
   open -> f1 -> f2 -> close
   etc...
   Each time, asserts should be used to ensure the results are as expected (exact matches are preferrable).
3. Lenders-borrowers tests. The goal is to ensure the the services and the vaults react to changes in the the services and the vaults themselves in a predictable way. Using pranks, the services and vaults should be altered in a fuzzy and randomized way, and the open-close-quote flow should be interlaced with deposit-withdraw-mint-burn randomly. For example, we can do
   open(1) -> withdraw -> open(2) -> close(1, loss) -> deposit -> burn -> open(3) -> deposit -> withdraw -> close(3, profit) -> ...
   withdraw -> open(1) -> mint -> close(1, loss) -> withdraw -> open(2) -> deposit -> ...
   etc...
   Each time, asserts should be used to ensure the results are as expected (exact matches are preferrable).

Every time, always randomly and fuzzily, we can add also timestamp warps and block shifts.