Switch to Foundry cheatcodes from DSTest

[palinatolmach]

As @lucasmt identified, a failed DSTest assertion such as assertLt does not cause the test to revert and fail immediately. Instead, fail() function stores bytes32(uint256(0x01)) at the storage slot bytes32("failed"), which is only checked at the end of the execution as part of foundry_success predicate. Although it is probably expected behavior, it would be more efficient if we allowed Kontrol to identify the test as failing sooner if a DSTest assertion check has failed.

Behavior of DSTest assertions such as assertEq changed to revert immediately with forge-std >= 1.8.0, where support for DSTest was dropped in favor of native Foundry assertions (vm.assertEq(...)), which causes errors such as

  Node id: 22
  Failure reason:
    Matching failed.
    The following cells failed matching individually (antecedent #Implies consequent):
    K_CELL: #error_foundry selector ( "assertEq(uint256,uint256)" ) b"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc0\xff\xee\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc0\xff\xee"
    ~> #return_foundry 160 0
    ~> #pc [ STATICCALL ]
    ~> #execute #Implies #halt ~> .K
    ~> CONTINUATION:K
    ACCOUNTS_CELL: <account>
...

[anvacaru]

@palinatolmach I think that we can close this one.

[palinatolmach]

Mostly addressed by #507 and #558, a remaining portion of assertions will be added in #562.