Extend execution-error assertion macros with patter and any arms

[marijamijailovic]

Closes #2807

Adds two new arms to assert_execution_error! and assert_transaction_executor_error!:

• matches <pat> [if <guard>] - pattern-match the inner ExecutionError directly, with an optional guard. Useful for variants other than FailedAssertion, or to assert on a specific err_code.
• any - accept any Err.

The existing $expected arm still works as before; tests passing MasmError constants don't change.

New tests/assertion_macros.rs:

• Macro grammar - each arm exercised against hand-built errors, plus #[should_panic] checks for the failure paths.
• VM-driven - small MASM programs run on FastProcessor to trigger and assert real ExecutionError variants end-to-end (DivideByZero, CycleLimitExceeded, MemoryError::UnalignedWordAccess, AdviceError::StackReadFailed, EventError, etc).

[Keinberger]

@marijamijailovic Would you mind fixing the broken lint workflow? Seems like something is ill-formatted.

[marijamijailovic]

@marijamijailovic Would you mind fixing the broken lint workflow? Seems like something is ill-formatted.
Thanks @Keinberger, formatting should be fixed

[marijamijailovic]

Changelog check is failing now – should we add the ‎no-changelog flag to this PR, or include an entry in the changelog?

[PhilippGackstatter]

Looks good! I left a few small comments.

[PhilippGackstatter]

Looks good to me, thank you!

[mmagician]

@marijamijailovic could you please not force push in the future, especially after the changes have already been reviewed? Incremental changes are much easier to review, while a force push looks suspicious as the contributor might have pushed completely unrelated malicious code (not saying this is the case here but just regarding the process). Thanks!

[marijamijailovic]

@marijamijailovic could you please not force push in the future, especially after the changes have already been reviewed? Incremental changes are much easier to review, while a force push looks suspicious as the contributor might have pushed completely unrelated malicious code (not saying this is the case here but just regarding the process). Thanks!

Sorry about that and thanks for pointing it out @mmagician. I’ll stick to incremental commits after reviews.

[mmagician]

nit: if I'm reading this correctly, then these are two distinct use cases. I'd maybe rephrase to make the distinction explicit:

/// Use this when you need to:
/// - match a variant other than `FailedAssertion` (e.g. `CycleLimitExceeded`, or
/// - pin a specific `err_code` on a `FailedAssertion`