Investigate effects of disabling libevmasm CSE after the Yul optimizer.

We're currently running the full libevmasm optimizer after the Yul optimizer, including complex parts like ``libevmasm``'s ``CommonSubexpressionEliminator``.

There is multiple reasons for this being suboptimal:
- Accurately transporting debugging data across the libevmasm CSE may be challenging.
- The libevmasm CSE has seen little development or maintanence in recent years.
- Running complex transformations on the assembly may skew our evaluation of the Yul optimizer. Ideally, most complex transformations are done on the Yul level (and if necessary on the level of the EVM code transform), and on the assembly level we'd merely perform transformations based on concrete opcode sequences (like the low-level inliner and the libevmasm peephole optimizer).

However, disabling the libevmasm CSE currently still induces gas and/or code size regressions. Conversely, libevmasm CSE can also apparently actually *hurt* gas costs. The range seems to be around +/- 1% runtime gas or deployment cost.

So what we should do is:

- Properly evaluate the effect of disabling the libevmasm CSE after the Yul optimizer.
- Examine the worst regression cases and try to find flaws in the Yul optimizer or code transform and schedule solving them as separate tasks.