s/id/esid

Fixes #477

Add tests for _TypedArrays_(object) using object properties

Add Object.getOwnPropertyDescriptors tests

Add coverage for 'name' property of Intl built-in functions

Update tests for Reflect.enumerate and Proxy enumerate trap

Ref #495

Ref #495

Ref #495

Ref #495

Fix test for TypedArrays.from on callable function

TypedArrays constructors are still callable even if they trigger a
TypeError Exception when a new target is not defined

Per https://github.com/tc39/test262/pull/484#discussion_r53228232

Remove unused harness file

Avoid Race Conditions in Test Runner

Promise: Add tests to disallow faulty optimization

Promise: Add test for constructor access count

Reorganize tests for Annex B extensions

Add tests for [[SetPrototypeOf]] on immutable prototype exotic objects

Add tests for _TypedArray_ constructors

The harness file `Test262Error.js` has not contained executable code since it
was introduced in this project [1]. The definition of the `Test262Error`
function has consistently been located in the `sta.js` harness file which test
runners are expected to inject into the test environment.

Remove the file and all references to it.

[1] See commit c33bf0e0

Object.prototype is extensible and an immutable prototype exotic object,
it's [[Prototype]] value is null

Ref tc39/ecma262#308

When executing multiple tests in parallel, each "child" thread would
write to the process's standard output buffer immediately upon test
completion. Because thread execution order and instruction interleaving
is non-deterministic, this made it possible for characters to be emitted
out-of-order.

When extended to support multiple concurrent threads, the runner was
outfitted with a "log lock" dedicated to sharing access to the output
file (when applicable). Re-use this lock when writing to standard out,
ensuring proper ordering of test result messages.

A recent extension to the test runner introduced support for running
tests in parallel using multi-threading. Following this, the runner
would incorrectly emit the "final report" before all individual test
results.

In order to emit the "final report" at the end of the output stream, the
parent thread would initialize all children and wait for availability of
a "log lock" shared by all children.

According to the documentation on the "threading" module's Lock object
[1]:

> When more than one thread is blocked in acquire() waiting for the state
> to turn to unlocked, only one thread proceeds when a release() call
> resets the state to unlocked; which one of the waiting threads proceeds
> is not defined, and may vary across implementations.

This means the primitive cannot be used by the parent thread to reliably
detect completion of all child threads.

Update the parent to maintain a reference for each child thread, and to
explicitly wait for every child thread to complete before emitting the
final result.

[1] https://docs.python.org/2/library/threading.html#lock-objects