fix: refactor codegen

[bitwalker]

This PR is a complete rewrite of major potions of the codegen backend. A fair amount of it remains as-is, namely the operand stack data structure, and the low-level instruction lowering code, but all of the stackification/instruction scheduling code has been rewritten from the ground-up.

Fundamentally, it still is based around the dependency graph/treegraph data structures for scheduling blocks, but the actual backend is now split into three phases, two of which are explicitly separated in different modules:

1. Planning/Scheduling

• The planning phase walks the constructed treegraph for each block in topological order, and queues up high-level scheduling tasks in what amounts to a bottom-up sketch of the block schedule
• The scheduling phase pops tasks of the queue for each block and produces a precise instruction schedule

2. Code Generation

• This phase emits code for each block in the function using the instruction schedule produced by the scheduler

One of the new things that was introduced here, is a rather complex, but powerful framework for scheduling instruction operands as efficiently as possible. Read the documentation for the OperandMovementConstraintSolver struct for more details on the problem and how it solves it, but the long and short of it is that it attempts to produce a set of minimal stack manipulation instructions that will transform the stack into the desired layout. It has one general approach, and a number of pattern-based heuristic approaches that it will attempt in order to find an optimal solution within a bound. We can tweak how much optimization is done by default, as well as at each optimization level, and can add more patterns as we identify them. The hope is that we can lean on this to produce code that is as efficient as what you would write by hand (in terms of manipulating the stack).

Put all together, this PR addresses a number of major bugs with the code generator, including #56 (though that test is still disabled due to how we're compiling and running modules with the assembler at the moment, but the actual bug mentioned in that issue is fixed).

This needs to be merged in order to unblock a fair amount of our other ongoing work, but feel free to take your time reviewing and asking questions, since there is a lot here, and I'd like to make sure you feel like you have a solid grasp of it (or at least feel comfortable that you could get there if need be).

[greenhat]

Great job! Just minor notes and nits. I appreciate the detailed comments you provided in the critical areas.

I went into a thorough analysis of the dependency graph, tree graph, scheduler, and the stack operand movement constraint solver. I believe I now have the best understanding possible by studying the code. I am fully prepared to debug and make any necessary changes when an opportunity arises.