internal: split vmgen/linker state from TCtx

[zerbina]

Summary

Move much of the data and associated types for the VM code generator and
linker into vmgen and the new vmlinker module. Having the code-
generation-related state in the vmgen module, means that the VM code-
generator state can now depend on modules that should not be a
transitive dependency (through vmdef) of all other VM-related modules.

Details

The linker-related types IdentPattern and LinkIndex plus the
routines for working with them are moved to the vmlinker module -- the
linker-related state is moved into the new LinkerData type. Due
vmcompilerserdes currently requiring access to the link table, the
LinkerData instance has to be still stored with TCtx instead of
the more correct JitState.

For the VM code generator, all relevant types, except for the
diagnostics, are moved from vmdef into vmgen. The TCtx used by
vmgen is now an alias to the new CodeGenCtx type, which stores all
the input, output, and other contextual state required for code
generation.

When using vmjit, much of the data read or written to by the code
generator is part of the VM execution environment (TCtx), and in order
to not having to either use pointers or pass all of it along as
procedure parameters, the relevant data is swapped between TCtx and
CodeGenCtx both before and after invoking the code generator.
vmjit.genExpr is slightly adjusted for this to work uniformly across
the genX procedures: it now also emits an Eof instruction.

vmbackend now stores an instance of CodeGenCtx instead of TCtx.
Once code generation is finished, a temporary VM execution environment
is set-up, populated, and then serialized.

Finally, vmrunner is updated to not rely on (now non-existent)
TCtx.callbackKeys field. The list of expected override patterns is
instead taken from the packed context and passed to registerCallbacks
directly.

[saem]

Looks good, I like how vmdef is becoming more focused and the modules become more independent of each other.

I did find a comment typo, but it's non-blocking. The suggestion for documenting the invariant is also non-blocking, just occurred to me that the trick with more DOD style approaches is signalling cardinality/relationships of the data contained therein -- I might be mistaken.

[saem]

/merge

[github-actions]

Merge requested by: @saem

Contents after the first section break of the PR description has been removed and preserved below:

---

Notes for Reviewers

• part of the endeavor of splitting up TCtx
• prepares for further improvements/simplifications of CgNode, as those will require new data types that should be imported into vmdef