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

Assert that the `constructor` property of the "this" value of
`Promise.prototype.then` is accessed exactly once. This guards against
implementations where repeated access is used instead of reference
passing (possibly motivated by convenience).

Repeated access of this kind was demonstrated by V8's implementation of
the specification:

https://bugs.chromium.org/p/v8/issues/detail?id=4539

Add tests that assert behavior when a Promise is resolved with another
Promise whose `then` method has been overridden. Because all objects
with a `then` method are treated equivalently, the presence of a
[[PromiseState]] internal slot should have no effect on program
behavior.

These tests guard against a faulty optimization originally implemented
in V8:

https://bugs.chromium.org/p/v8/issues/detail?id=3641

The "mainline" tests in Test262 are converging on a more formal
structure. Files are organized as tests for either either "language"
(e.g. syntax-driven) or "built-in" (e.g. API-driven). "Language" test
locations are themselves structured according to whether the syntactic
form under test is an Expression or a Statement.

To limit ambiguity when locating/adding tests, re-organize the tests for
Annex B extensions to match this structure.

Enable parallel test execution in console runner

Adds a `-j`/`--workers-count` parameter to `tools/packaging/test262.py`, defaulting to `[number of cores] - 1`.

Speeds up running the test suite by about ~3x on my 4-core machine, with the SpiderMonkey shell. This could certainly be optimized more by just appending test results to per-thread lists and merging them at the end, but it's better than nothing.

Add tests for zero conversion on Array#indexOf and Array#lastIndexOf