Stack layout generator stack compression oddity.

[ekpyron]

Noticed in #15844

The thought behind the line changed here was to always minimize the propagated stack, if the required value can be dup'ed ad-hoc, but the counting was off (not even by just 1, but by 2 slots).

However, while this change improves gas cost on some tests, it triggers a stack-too-deep in an external test (this is likely due to a non-local effect of the change, which is hard to directly mitigate).

So I'd tend towards keeping the existing logic and towards fixing this with generally improved stack layout generation in the SSA codegen approach. I'm still pushing a draft PR for now to consider options.

[ekpyron]

Without the change, this dup16 will instead be transported up and turn into a dup14 plus some swapping to compensate.

[ekpyron]

The actual stack-too-deep failure in elementfi is actually also a bit curious. First of all, it's weird that this change triggers it - the change should actually make stacks smaller - but it will keep additional copies of slots around further up in the code, which it appears to just happen to prevent the stack-too-deep in elementfi.
But futhermore, the stack-too-deep error itself indicates that there is quite a few function return labels on stack when the stack-too-deep happens - I actually thought, if we run into stack-too-deep, we do another pass and aggressively compress the stack, which should remove all these - however, we only do that within blocks, so this may be cross-block shuffling that fails here.

In any case, I'd actually tend towards not messing with this, even though the current behaviour is odd here, but to instead focus on bringing the SSA-based code transforms up to speed, which should be much more well-behaved in general.