Align TLOAD/TSTORE opcodes with Ethereum EIP-1153 addresses

[GheisMohammadi]

Moves TLOAD and TSTORE opcodes to match Ethereum's EIP-1153 specification addresses (0x5c and 0x5d) instead of the previous Harmony-specific addresses (0xb3 and 0xb4).

• TLOAD: Moved from 0xb3 → 0x5c
• TSTORE: Moved from 0xb4 → 0x5d
• Updated opcode-to-string mapping to reflect new positions in the 0x50 range

[Frozen]

hey @GheisMohammadi, i updated harmony version from 1.9.x to exactly 1.10.26 and later on to 1.11.6
Version 1.11.6 https://github.com/ethereum/go-ethereum/blob/v1.11.6/core/vm/opcodes.go#L209 has exaclty

	TLOAD  OpCode = 0xb3
	TSTORE OpCode = 0xb4

mappings.

With which etherium version you align with?

[GheisMohammadi]

hey @GheisMohammadi, i updated harmony version from 1.9.x to exactly 1.10.26 and later on to 1.11.6

Version 1.11.6 https://github.com/ethereum/go-ethereum/blob/v1.11.6/core/vm/opcodes.go#L209 has exaclty

	TLOAD  OpCode = 0xb3

	TSTORE OpCode = 0xb4

mappings.

With which etherium version you align with?

Your link points to a version from almost three years ago.
In Harmony, all VM opcodes already follow the latest Ethereum opcode values. This PR intentionally updates TLOAD and TSTORE to the finalized Ethereum addresses, even though the underlying codebase is still based on an older Geth fork.

Keeping the old opcode values would actually be worse, because it would require an additional fork later just to migrate to the finalized addresses. It also creates an inconsistency: it doesn’t make sense for all other opcodes to match the latest Ethereum spec while these two continue using deprecated draft values.

On top of that, we already support EIPs that landed much later (some as recent as 2025). Given that, sticking to outdated opcode addresses is inconsistent with the rest of the VM and Ethereum compatibility goals.