Adjust Yul optimizer to rematerialize zero literals.

[NunoFilipeSantos]

No description provided.

[ekpyron]

The high-level task here is:
We never want to produce bytecode that uses a DUP[N] opcode for dupping up a constant literal zero, since PUSH0 is cheaper than any DUP.

We already have the LiteralRematerializer in the optimizer (part of Rematerializer.cpp), which replaces all variables with their literal value and which occurs as T in the optimizer sequence.

However, after literal rematerialization we run the Common Subexpression Eliminator again, which will reverse this, i.e. which will replace multiple uses of a variable with the same constant value by multiple references to that constant.
The CSE already has a special case for not doing this for return variables; see the comment

				// Prevent using the default value of return variables
				// instead of literal zeros.

in CommonSubexpressionEliminator.cpp.

The easy fix for this issue is to generalize that logic to all occurrences of zero, in case the EVM version supports PUSH0 (which can be queried from the EVMVersion which should be accessible via the Yul dialect in the optimizer step).

We should then check if any other optimizer steps suffer due to this, i.e. if the data flow analyzer, etc., keep working as intended with this change. I'd expect everything will be fine, but if we see unexpected gas cost increases or the optimizer fails to simplify anything, we'll need to dig into that.