Relative objects in wasm

[graydon]

This is a much simpler approach to the "object read-access-control" problem covered in PRs #940 and #930 (and previously #132). The idea here is:

1. We split object references as before in two types differentiated by their low bit, but now they're "absolute" and "relative". Relative references indirect through a context-local table that just holds absolute references.
2. We only really care about this issue when dealing with wasm contracts. Local-testing / native contracts have no isolation / complete system visibility anyways, there's no point really worrying about "who can see what".
3. Therefore the wasm VM argument-marshalling path is a natural point to do the relative-to-absolute translation. We translate relative references to absolute on the way in to the host, and absolute to relative on the way out. Wasm never gets to see any absolute references. If they forge one, we refuse it on the way in.

(There is a slight downside in the current implementation which is that if you return the same absolute reference multiple times we'll create new relative references on each return. If this is annoying we can use a hashtable or something instead of a vector. But the vector has both performance and conceptual simplicity on its side, and in any case the user shouldn't care about specific object references, and I expect most contracts do not run long enough or return the same object references repeatedly enough for this to matter either way)

[graydon]

@dmkozh I believe this is ready to go now, and is as minimal as I can make it. I added a test and localized the changes to the host (and actually just the VM frame type). At this point more of the diff is just legibility change (I changed the VM frame type from a tuple to a struct) than anything else.