Defer evaluation order of computed properties

[bnoordhuis]

The evaluation order is observable. Align with what test262 expects.

[bnoordhuis]

Hm, that failing test262/test/language/expressions/assignment/S11.13.1_A7_T3.js test seems to be almost 100% at odds with the two fixed tests... guess I'll have to think about this a bit more.

[bnoordhuis]

For posterity, the fixed tests both have this in their description (and is what this pull request currently implements):

Assignment Operator evaluates the value prior validating a MemberExpression's reference

Whereas the now failing test says this:

The left-hand side expression is evaluated before the right-hand side.

Looking at the three tests, the expected evaluation order in o[k] = f() seems to be:

1. f(), o, k when o is null or undefined, but

2. k, o, f() when o is an object. Seriously.

[bnoordhuis]

I think I have it working although it's not very pretty or efficient... PTAL.

[bnoordhuis]

@saghul your thoughts on this approach por favor?