Memory sandboxing

[udoprog]

The following are enumerations of missing pieces for supporting memory sandboxing. Note that this is not an exhaustive list:

• [ ] The stack is not limited. So sufficiently nested code could use up unsupervised amounts of memory.
• [ ] Allocation metadata is not accounted for, so in particular many small allocations might end up using up more system memory than what is being accounted for. This plugs in at the Rust allocated level, and uses the global allocation APIs which are currently provided in stable. This could eventually be remedied using a custom allocator, or by using an allocator which reports overhead.
• [ ] CLI arguments. This is not critical since the CLI is usually not fed untrusted input.
• [ ] Sorting using [_]::sort, which uses timsort that might allocate a cache up to half the size of the elements being sorted.
• [ ] Path / PathBuf and I/O related functions uses their std counterparts. But they (and filesystem interactions) can be disabled by disabling the std feature or configuring the source loader to not use a filesystem based one.
• [ ] RelativePath / RelativePathBuf which is used in some places internally.
• [ ] Anything using serde. While any types we convert into will take allocated memory into account (and error through serde accordingly) serializations might use internal buffering which bypasses this, such as serde_json using a string buffer. Owned types being passed in are not accounted for until they've been converted to internal types.
• [ ] So far Rc and Arc have not been forked. Mainly because their memory overhead is fixed and relative to other collections which store them internally, We might still decide to fork them to ensure that we get full coverage.
• [ ] A few more internal uses of std / alloc types such as String and Vec which just haven't been ported yet because they're not considered important (#635).