This makes it a lot easier to understand what is going wrong when an
eval test fails. As an example instead of just getting:
`ExpectationError`
You would now get:
`ExpectationError: Expected _1_2E+0_1_ to eval to _12_ but got _120_`.
This requires variables that should be exported to the script host
or to other scripts to be declared as var (such as in test-common.js),
since lexically-scoped variables won't be visible.
This regressed recently and would only output a bunch of '[object Foo]',
the reason being that String(value) failed in some cases - which is
easily fixed by trying that first and using Object.prototype.toString()
as a fallback in the case of an exception :^)
Since we have had eval() for a while now, we can finally use it here -
this allows us to get rid of the confusing return statements in tested
source code.
Using String() like we did before depends on objects having either
toString, valueOf, or @@toPrimitive, which is not the case for objects
with no prototype.
The test-js program expects this to exist for 'result: "fail"' results
and would crash if any duplicated test(message) occurs, as we didn't
provide 'details' in that case.