feat(hog): bytecode versions

[mariusandra]

Problem

Continuing extraction from #24369

Changes

• Add a version field to Hog bytecode.
• Introduce version 1, which turns around the order of arguments on the stack for function calls. This makes it possible to support optional arguments in the future.
• Rename op.CALL to op.CALL_GLOBAL
• Throw if trying to access a global variable that's not found
• Small cleanup here and there

How did you test this code?

Updated many tests

[benjackwhite]

Mostly looked at tests. I'm assuming then at some point we will need a migration layer to ensure backwards compat? I couldn't quite parse in all the code if there is a chance other than supporting a version index?

[mariusandra]

Other than the version integer in the bytecode, the code also 1) flips around the arguments in function calls when using the new version, 2) changes CALL to CALL_GLOBAL, 3) throws on undefined global access

All of it is effectively housekeeping in order to make the next extracted PR (actually lambdas and function refactors) easier to swallow.

We won't need a migration as long as we keep the if version != 0 check in one place in the VMs. I explicitly built it this way so that we wouldn't need a breaking "rebuild all" migration for Hog functions.