feat(cheatcodes): add event expecter which supports anonymous events

[lightclient]

closes #7457, closes #7545

--

From #7545:

Add support for a new cheatcode: vm.expectEmitAnonymous(bool checkTopic0, bool checkTopic1, bool checkTopic2, bool checkTopic3, bool checkData) (and corresponding equivalent overloads).

The rationale is that vm.expectEmit always checks topic0, which is the event signature, and checking everything else is optional. But with an anonymous event, you don't have an event signature, so it doesn't make sense to still force the user to check topic0.

This PR introduces the vm.expectEmitAnonymous cheatcode and corresponding overloads. Additionally, it disallows matching anonymous events with no indexed topics via vm.expectEmit. If the anonymous has at least one indexed event, it's impossible to differentiate from a non-anonymous event.

The restriction is necessary, because the way vm.expectEmit works is surprising (see #8416). The value checkTopic1 is basically disregarded. Since Solidity uses it to encode the event signature, it is the best way to match the signature between the expected event and actual.

The ideal solution would be to break this interface and only allow checking of 3 topics via expectEmit, since that is essentially what's possible now.

[klkvr]

The ideal solution would be to break this interface and only allow checking of 3 topics via expectEmit, since that is essentially what's possible now.

Sorry, don't think I am following. I believe that expectEmit already only allows checking only 3 topics (topic1, topic2 and topic3, topic0 being reserved for event signature).

However, I'd expect expectEmitAnonymous to allow matching all 4 topics with signature vm.expectEmitAnonymous(bool checkTopic0, bool checkTopic1, bool checkTopic2, bool checkTopic3, bool checkData)

[lightclient]

Sorry you're right - I got confused by the 4th element in checks but that's actually the data. Let me fix.

[lightclient]

Okay I updated. Let's see what CI thinks.

[DaniPopes]

lgtm, pending @mattsse @klkvr

[klkvr]

I think we'd want to revert here ideally, should be possible after bluealloy/revm#1610

[klkvr]

LGTM