stopOnFailedContractMatching can be confusing for users

[gustavo-grieco]

Medusa will refuse to run in the following example:

$ git clone https://github.com/crytic/properties -b dev-medusa
$ cd properties/tests/ERC4626/foundry
$ forge install
$ medusa fuzz --target . --deployment-order CryticERC4626InternalHarness --config medusa-config.json
...
Error: could not match bytecode of a deployed contract to any contract definition known to the fuzzer

It is unclear why it fails to match some bytecode (it could be related with the usage of some kind of proxy). Disabling the stopOnFailedContractMatching option allow to run the tool, and the results looks good. However, for users, it will be difficult to under that this needs to be disabled. I can understand the reason behind returning an error if the contract bytecodes are not matched, but I think a big visible warning (per contract) should be better.

[Xenomega]

This was necessary when crytic-compile had a fatal bug and we still wanted to work around it, so it should be less relevant now if I remember correctly. I don't think there were any other meaningful edge cases.

My thoughts are we can hide it (not serialize) in the project config (JSON) to simplify UX, but keep it in the struct internally if we want to enforce it in our testing suite or let people want to set it on a Go API level.

[gustavo-grieco]

I think this is no longer relevant, I cannot reproduce the issue, even with stopOnFailedContractMatching == true.