perf: optimize jump table initialization and reuse

[lily309]

What does this PR do?

• Removes unused historical version entries and eagerly initialized table mappings while retaining the existing operation-set builders.
• Centralizes the newest operation set selection through LATEST_VERSION and newLatestOperationSet().
• Creates dedicated instances of the latest jump table for transactions and constant calls.
• Reuses both tables across executions.
• Applies configuration-dependent adjustments once per top-level execution.
• Reuses the prepared table for nested contract calls and contract creation.

Why is this needed?

The previous implementation initialized jump tables for multiple historical versions even though only the latest version was selected for execution.

Transactions and constant calls also shared the same table, which allowed adjustments made for constant calls to affect transaction execution. In addition, configuration-dependent adjustments could be applied repeatedly during nested calls and contract creation.

This change centralizes the selection of the latest operation set and separates transaction and constant-call tables. It reduces startup initialization and repeated adjustment overhead while keeping the two execution paths isolated.

Tests

• Added coverage for transaction and constant-call table isolation.
• Added coverage for table reuse across executions.
• Verified that constant-call adjustments do not affect the transaction table.
• Verified transaction, constant-call, nested-call, and contract-creation execution paths.
• Verified existing instruction and configuration-dependent behavior.