While I don't expect every host object to implement it correctly, this also gets rid of a lot of unnecessary `unwrap` calls that would allow a poorly-written Flash file to kill the interpreter.
Note that host objects that do so will *not* have access to their standard representation from within member functions - you will need to extend the interface to accomodate for them. This is due to long-standing limitations with type IDs and downcasting with types that bear lifetimes - it's entirely an unsafe operation and exposing such a facility to safe Rust is unsound. However, this will at least let us separate out several things from ScriptObject that don't need to be there for the time being.
`Object::function` now returns a pre-allocated function object. You may supply it an explicit prototype to have it linked into the function object (which is why we have to return a cell).
The previous behavior had an oversight: if you tried to set a variable with the same name as an in-scope property, it would always try to overwrite that property. This can fail silently and doesn't match with Flash Player behavior. Now, an attempt to overwrite a read-only property is instead correctly rejected so that it can be defined in local scope.
This type explicitly signals if an immediate value is to be returned, if a value is to be returned on the stack, or if no return value is to be generated. Holders of a `ReturnValue` can also use `and_then` to schedule a `StackContinuation` to be executed when and if that value is ready.
`StackContinuations` now yield `ReturnValues` as well, so they have a moderate level of composability. For example, if you need to get a property from an object and push it on the stack, you can return the result of calling `get` directly and the machinery ensures it eventually gets there.
This involved yet another macro, `and_then!`, to avoid a ridiculous amount of duplicate code. It calls a continuation whenever it's value is ready, even if the value resolved on the Rust stack.
`locals_into_form_values` does not currently support this. It skips any property that does not resolve on the Rust stack. Future work is required to resolve this.
This involves the use of a "stack continuation" system. Due to previous lifetime issues with using closures directly (see `8ea6c6234dba925ec5fbc61502627fb62b05916c`), we instead use a macro that constructs a `Collect`able type holding the things the continuation needs to continue working with. The syntax is largely similar to Rust closures but with the addition of an explicit list of bound variables, all of which must be `Collect`.
David Wendt