Split should_fail tests to tests that don't compile and tests that compile but revert

[kayagokalp]

We could split should_fail tests into:

1. tests that don't compile
2. tests that compile but revert

If we have a folder structure like this it could be a little easier to understand the output of the test suite. Currently reviewing the output of the test suite one can think that the should_fail/x test is passing incorrectly as it does not print some kind of failure message if it is a reverting test case.

[otrho]

Since #2003 the E2E tests are all config driven, and whether they pass or not is decided by their individual TOML files. The only real benefit to having tests grouped into a directory structure is for filtering.

A regex may be passed on the command line to filter which tests are run (e.g., cargo run should_fail/abi) and the filter is on the test path. So this is an argument for reorganising tests -- e.g., filtering on should_fail/reverts.

But an alternative might be to add tags to test TOML to which the filter could be applied. This might allow us to run any test which is a contract, regardless of the test type -- fail or not, etc.

We could also add a command line option to only run tests of the specific type from the category field in the test.toml or the expected_result field. E.g., to run all the tests which revert: cargo run -- --expected "revert".

I think watching the test output and looking for certain outputs based on their type isn't really useful. Ideally tests would be completely silent when they pass (even if 'passing' is failing).

[mohammadfawaz]

Closing in favor of #2690. test.toml has everything we need now and there is no need to separate things into folders like that. (unless the folders categorize tests based on their "topic" and not pass/fail status).