Implement BaseFee, blobBaseFee, CallValue, GasPrice, Balance and SelfBalance for EVM v2

[ahamlat]

PR description

Continues the EVM v2 implementation started in #10105.

Implement V2 versions of five Wei-related opcodes operating directly on the long[] stack: BALANCE (0x31), SELFBALANCE (0x47), BASEFEE (0x48), BLOBBASEFEE (0x4a), CALLVALUE (0x34), and GASPRICE (0x3a).

The stack long[] array is not exposed beyond the operation boundary. Each operation is solely responsible for manipulating the stack: reading inputs, writing results, and updating the stack top pointer. The shared helper methods (pushWei, pushZero, toAddressAt) are deliberately simple write/read primitives that operate on a given slot index -- they have no knowledge of the stack top and do not return or update it. The caller (the operation's execute method) is responsible for computing the correct slot indices and deciding whether/how to update the stack top based on its own pop/push semantics.

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests
• hive tests: Engine or other RPCs modified?

[siladu]

Wonder if there's any advantage to this field over referring to txValues.maxStackSize in line?

[siladu]

Suggested change

	private final int stackMaxSize;
	private final int stackMaxSizeV2;

[siladu]

I thought we discussed and agreed to introduce AbstractOperationV2 as duplicate of AbstractOperation - has your thinking changed on that?

If we prefer mixing V1 and V2 code together, then perhaps we should mix AbstractFixCostOperationV2 as well so we're sticking to a single convention for V2.

[siladu]

Do changes here impact V1?