fix(cheatcodes): Correct expectRevert behavior

[Evalir]

** This is a big breaking change**

Motivation

Closes #3723 , Closes #3437 , Closes #4832 .

expectRevert currently has incorrect behavior: it matches reverts at the test level, not at the next call level. This means that reverting cheatcodes were being incorrectly catched by expectRevert (we're supposed to bypass checks for cheatcode calls) and also let users use the cheatcode incorrectly as illustrated in #3723.

Solution and Behavior

expectRevert now only works on the next CALL. Cheatcode calls are now ignored properly, even if those cheatcode calls revert. To illustrate, these are examples of now legal/illegal behavior:

// OK
function testExpectRevertString() public {
    Reverter reverter = new Reverter();
    cheats.expectRevert("revert");
    reverter.revertWithMessage("revert");
}

// FAIL
function testFailRevertNotOnImmediateNextCall() public {
    Reverter reverter = new Reverter();
    // expectRevert should only work for the next call. However,
    // we do not inmediately revert, so,
    // we fail.
    cheats.expectRevert("revert");
    reverter.doNotRevert();
    reverter.revertWithMessage("revert");
}

// FAIL
function testFailCheatcodeRevert() public {
  // This expectRevert is hanging, as the next cheatcode call is ignored.
  vm.expectRevert();
  vm.fsMetadata(fakePath) // try to go to some non-existent path to cause a revert
}

On tests marked as "not working properly"

As you can see, the diff is extremely minimal in terms of the change itself. This has uncovered a few tests which are not working as expected anymore—mainly because they were relying on the broken expectRevert behavior. Some of them seem to be bugs—mainly the fs/parsing related ones.

NOTE: This PR is done—just needs a coordinated forge-std release once this goes on main, which won't be soon.

[Evalir]

Working on the forge-std tests—the behavior change also breaks some tests there