Kontrol tests cannot be analyzed by Foundry

Based on a discussion with @lucasmt:
The tests we are symbolically executing heavily rely on KEVM cheatcodes, such as kevm.symbolicStorage() and kevm.infiniteGas(). This introduces two issues:

1. Foundry supposedly fails upon encountering a cheatcode it doesn't recognize (will confirm).
   The potential workaround is to treat KEVM cheatcodes as calls do a different address other than the one used by Foundry and hevm (e.g., keccak256("kevm cheat code"), that's what Halmos does), but that would probably require deployment of a contract with KEVMCheats interface at that address so that Foundry doesn't crash on calls to that contract.
2. Tests that rely on symbolic storage cannot be meaningfully fuzzed.
   Storage variables in the latter case are all going to be zero, disabling most of the execution paths. Perhaps, it would help to fuzz the state/storage too: to some extent, this can be achieved through vm.store() and/or vm.assume() Foundry cheatcodes, but it introduces significant performance overhead, and it's unclear how to implement that for contracts with complex storage layout.

Start by reproducing Foundry's behavior when Kontrol tests invoke KEVM cheatcodes such as kevm.symbolicStorage() and kevm.infiniteGas(). Then investigate how symbolic storage affects fuzzing, including the proposed vm.store() and vm.assume() approaches; done means KEVM tests can be analyzed with meaningful storage-dependent paths without unacceptable overhead.