Expose DefaultMemoryCreator in wasmtime_runtime's API

[Mrmaxmeier]

This exposes the standard implementation of RuntimeMemoryCreator in wasmtime_runtime's API and thus allows indirectly using the handy but private MmapMemory implementation.
Exposing DefaultMemoryCreator in wasmtime-runtime seems mostly harmless. Feel free to reject this though and/or yell at me for not opening an issue first.

---

Memories can also be created with OnDemandInstanceAllocator (pub) which can fall back to DefaultMemoryCreator internally.
This requires passing in a Module though, which might not be relevant when looking to create memories.

[alexcrichton]

FWIW the wasmtime-runtime crate is effectively a "private" crate which is not maintained from the perspective of having a pleasant-to-use API, instead it's existence is basically entirely for the wasmtime crate. In that sense while we could merge this now there's very little preventing a future refactoring from undoing this.

Is there any particular reason though why you're using wasmtime-runtime as opposed to wasmtime?

[Mrmaxmeier]

Is there any particular reason though why you're using wasmtime-runtime as opposed to wasmtime?

I'm experimenting with Cranelift and a toy JIT. wasmtime-runtime's catch_traps and MmapMemory have been very useful for this 🙂

FWIW the wasmtime-runtime crate is effectively a "private" crate which is not maintained from the perspective of having a pleasant-to-use API, instead it's existence is basically entirely for the wasmtime crate. In that sense while we could merge this now there's very little preventing a future refactoring from undoing this.

^ This would be fine for me – I'm currently just rebasing this patch every once in a while and wanted to clean up git dependencies :)

[alexcrichton]

Ok, sounds reasonable to merge in that case!