Add support for mmapped memory in crashdumps and guest debugging

[dblnz]

Fixes #747 and is a blocker for hyperlight-dev/hyperlight-wasm#129.

This modifies the guest debugging by adding a DebugMemoryAccess type that handles the memory access for the debugger. It abstracts over the type of memory, shared or mmaped.

Additionally, we now include the mmapped memory regions in the crashdump.

[ludfjig]

This looks good to me, but it looks like we're circumventing our SharedMemory abstraction here with unsafe code like from_raw. Would it be possible to avoid this?

[dblnz]

That is true, but I think this is a consequence of how the mmapped memory is handled. As a separate set of regions.
What I think I could do is implement something similar to SharedMemory abstraction over the mmapped memory that keeps track of accessing and mapping/unmapping.

[ludfjig]

That is true, but I think this is a consequence of how the mmapped memory is handled. As a separate set of regions.
What I think I could do is implement something similar to SharedMemory abstraction over the mmapped memory that keeps track of accessing and mapping/unmapping.

Oh yeah forgot about that... That might be unfeasible

[dblnz]

I believe this PR touches on the Sandbox memory model discussion we need to have, specifically about how mmaped memory should fit into it. This is tracked in #956 .

[simongdavies]

That is true, but I think this is a consequence of how the mmapped memory is handled. As a separate set of regions.
What I think I could do is implement something similar to SharedMemory abstraction over the mmapped memory that keeps track of accessing and mapping/unmapping.

Oh yeah forgot about that... That might be unfeasible

I think we should go forward with this as is and then address the winder memory issues in #956