eof: Update yul legacy tests

[rodiazet]

Add bytecodeFormat: legacy to all tests which are supposed to run in legacy bytecode mode only.

[github-actions]

Thank you for your contribution to the Solidity compiler! A team member will follow up shortly.

If you haven't read our contributing guidelines and our review checklist before, please do it now, this makes the reviewing process and accepting your contribution smoother.

If you have any questions or need our help, feel free to post them in the PR or talk to us directly on the #solidity-dev channel on Matrix.

[cameel]

No problems here, but there are quite a few tests that can be easily made portable with small adjustments. And some cases where multiple tests are crammed into one file and we could easily restrict only one part and let the rest run for all backends.

[cameel]

Just a general note: there are a few tests like this one that don't necessarily need a separate EOF version, but are relevant to all the backends, not just legacy. Keeping them restricted to legacy runs the risk that in the future someone will assume that they can be dropped along with legacy backend. Not sure how to prevent that. Maybe we should revisit the PR and switch them to EOF when it becomes the default backend.

[cameel]

Nice. The original test had an unresolved mload() here.

This seems to be the practical effect of the fact that we have to assume that CALL writes memory but EXTCALL can only ever read it.

CALL's write could be figured out to have no impact but apparently we ignore its length.

[cameel]

But I just noticed something in SemanticInfo.cpp that looks like a bug:

solidity/libevmasm/SemanticInformation.cpp

Lines 184 to 188 in f632ec8

	if (_instruction == Instruction::EXTDELEGATECALL)
	{
	operations.emplace_back(Operation{Location::Storage, Effect::Write, {}, {}, {}});
	operations.emplace_back(Operation{Location::TransientStorage, Effect::Write, {}, {}, {}});
	}

Looks like we decided to mark EXTDELEGATECALL as writing storage/tstorage, but not EXTCALL, even though CALL is marked as such. I may have been thinking only about direct writes when I reviewed it but I guess EXTCALL can modify storage indirectly, by calling a function that can do that. We should fix that (and make sure there's a test where the difference shows).

[cameel]

There are still two unaddressed things here: #15658 (comment) and #15658 (comment). After that we can merge.