Remove legacy heap region from snapshot

[syntactically]

For historical reasons, we have a "heap" region of memory in the snapshot, which is just a bunch of zero-initialised pages that bound the size of the heap. These are, in theory, never read from, only written to (upon which they will get CoW'd anyway), and have no real purpose existing, but bloat the size of the snapshot image. They are also all distinct physical pages when they are implicitly created in from_env (the space for them is included in SandboxMemoryLayout::get_memory_size(), so they are created when we make a memory buffer of that size), so the logic that deduplicates pages by GPA does not even work on them.

We should remove this region, and replace it with a VA region outside the snapshot image region that is unmapped by default, and maps to zero when a fault hits it. We can essentially reuse the logic from the stack region for this.

[syntactically]

There are a number of options for how we could do this:

• Keep the current situation at the API, where there is a config-controlled heap size knob that sets the size of a VA reservation, but just find a way to avoid actually materialising it in the snapshot when it isn't needed
  • This could itself be done either by moving the VA region out of the currently-originally-identity-mapped-copy-of-snapshot space; or
  • We could leave it in place in VA space but change the PA space to not have that space, and making the original snapshot copy not-identity-mapped. There might be some slight perf benefit to this due to keeping the VA space more compact
• We could make the heap region "unbounded" (well bounded only by the scratch size available in a given run) by moving it to a new very large VA space and populating it on demand. Because the current allocator is not very good, I am not sure whether this might have some negatives for its performance/minimizing its memory demands.
• We could also make the heap region "unbounded" by moving it but only initialise the LockedHeap with a small subset of it, and then wrap the LockedHeap's allocator to hurriedly call add_to_heap whenever an allocation failed. We would have to double-check that the allocator's internal invariants allow ths.
• We could switch our allocator entirely to a different one (see Change our no_std allocator #343) that supports the more common large-system allocator pattern of, rather than having a fixed backing memory region, asking the "kernel" to provide some more memory when it runs out.