Risks of 32-bit memory address space and disabled GC

[norswap]

I seem to recall that the memory available to the MIPS version of Cannon is limited (2GB? 4GB?). We should check this, and make sure it's not possible to craft a set of blocks such that processing them would cause the memory limit to be exceeded.

~~We should also make sure memory is never written to the various "magic" memory location (input hash, output hash, preimage oracle input and output).~~ (update: registers and pre-image data are separate from memory now).

[norswap]

Important to keep in mind: we explicitly disable garbage collection (because it requires threading), so we need to be mindful of memory consumption. Every heap allocation is forever!

If we're able to stack allocate the per-epoch inputs (transactions and receipts), that would help a lot I think.

[protolambda]

The system state is now fully separated from regular program memory address space. And the pre-image oracle is now backed by read/write syscalls. So registers and state etc. are safe from accidental overwrites. There still exists a memory risk where we run out of available address-space, due to the lack of GC. Will update issue title and description to reflect this.