Fixes #489

Fixes #477

- Prefix file names to explicitly describe the "head" position
- Remove statement name suffix as this information is reflected by each
  file's location within the file hierarchy

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

ECMAScript 2015 introduced tail call optimization for function calls
occuring in a number of positions in the grammar. Assert expected
behavior by triggering a large (but configurable) number of recursive
function calls in these positions. Compliant runtimes will execute such
programs without error; non-compliant runtimes are expected to fail
these tests by throwing an error or crashing when system resources are
exhausted.

The ES2016 draft further refines the completion values for `if` and
`with` statements. Two tests must be removed outright because the
completion value in those cases is no longer accessible from the
runtime.

In order to facilitate proper tail calls, ES2015 modified the completion
value of a number of statements.

These tests use `eval` to verify the new values.

Although the `for..in` statement allows Expressions to define the
iterator, only an AssignmentExpression may occupy this position in the
`for..of` statement.

Add tests verifying that ASI can't occur after the leading let/const in |let let|, |let let = "...";|, and |const let = "...";|.  Each matches the LexicalDeclaration production, then triggers an early error before evaluation because it attempts to bind "let".

- lastIndex in RegExp.prototype[Symbol.split]: tc39/ecma262@08b4756747f9c967058239df627da544412740a6
- Missing number conversion in DataView.prototype.setXXX: tc39/ecma262@4f875fe96dcbd5e6363dd3d5b510cd5109199f5b
- Negative zero byteoffset in TypedArray: tc39/ecma262@2d1ed20db778e8f69f66ba76b351b9322fd38495
- EvalDeclarationInstantiation throws TypeError: tc39/ecma262@2be6968715946a4763f6ca8633e311ab7ce63577
- BindingRestElement allows BindingPattern: tc39/ecma262@d322357e6be95bc4bd3e03f5944a736aac55fa50
- Eval in parameters with computed property keys: tc39/ecma262@04e2e9b7197a33612202e85065e3f8d8385fbcef
- Use strict with non-simple parameters: tc39/ecma262@15b0db41edd0e519e94668bf13765fe458840766
- __proto__ in strict mode: tc39/ecma262@5c1984334d6d42538527bd022e68bfbfee5cb652

- RegExp.prototype[Symbol.split] calls ToUint32 (https://github.com/tc39/ecma262/issues/92)
- Species lookup removed from Promise.all and Promise.race (https://github.com/tc39/ecma262/issues/151)
- Generator functions are no longer constructors (https://github.com/tc39/ecma262/pull/171)

Fixes #444

- if-statement completion value semantics was not properly updated in ES2015

This change set includes tests for most invocations of the
SetFunctionName abstract operation in the ES2015 specification.
Practical testing considerations preclude the introduction of tests for
certain invocations:

- The project is still vetting methods to sustainably test the semantics
  of the Destructuring Binding pattern across all valid productions.
  - 13.3.3.6 Runtime Semantics: IteratorBindingInitialization
  - 13.3.3.7 Runtime Semantics: KeyedBindingInitialization
- Without a loader, there is no way to access a function object declared
  in an ExportDeclaration, so `name` assignment cannot be tested in
  these cases
  - 14.1.19 Runtime Semantics: InstantiateFunctionObject
  - 14.4.12 Runtime Semantics: InstantiateFunctionObject
  - 14.5.15 Runtime Semantics: BindingClassDeclarationEvaluation
  - 15.2.3.11 Runtime Semantics: Evaluation

- Remove duplicate word
- Add missing license

- Add missing 'negative: ReferenceError' in S7.9_A5.7_T1
- Remove stale 'negative: ReferenceError' in block-local-closure-get-before-initialization
- Remove all tail-call expressions in test/built-ins/Function
- And update code in test/built-ins/Function to simply use 'f()' instead of 'var r = f(); return r'

Fixes #383

The `negative` frontmatter tag expresses an expectation for the behavior
of the test file as a whole. The `assert.throws` helper function offers
more fine-grained control over expectations because it may be applied to
specific statements and expressions. This makes it preferable in cases
where it may be used (i.e. when the test body does not describe a syntax
error or early error).

Re-implement assertions for errors to use the `assert.throws` helper
function wherever possible.

The `test/language/class/` directory contains a small subset of
Test262's tests for ES2015 classes. The majority of tests for classes
are organized within `test/language/statements/class/`.

- Move the tests that rely on the ClassDeclaration syntactic form from
  `test/language/class/` to `test/language/statements/class/`.
- Move the test that relies on the ClassExpression syntactic form from
  `test/language/class/` to `test/language/expressions/class/`.

- Re-organize existing tests for identifiers
  Name files according to their content (not their ES5 ID). Move tests
  for IdentifierName and LabelIdentifier to more appropriate directories.
- Simplify and correct tests
  Instead of asserting successful runtime evaluation using `eval`, rely
  on the test runner's ability to detect syntax errors. Update the test
  bodies to test the grammar referenced by their ES5 ID and
  description--the IdentifierStart pattern.
- Use `negative` frontmatter to assert SyntaxErrors
- Remove redundant tests
- Use `assert.equal` helper function
- Add equivalent tests for literal unicode chars
- Add tests for variable-length unicode escape

The `test/language/generators/` directory contained a single file that
concerned generators derived both from syntactic form and from a
built-in function.

Refactor this test into two files and place each in the appropriate
directory.

Some tests specifically concern the application of the `use strict`
directive as it appears in JavaScript source code. These tests should
*not* be run with the `onlyStrict` flag because relying on the test
runner to enable strict mode makes the semantics of the source code
irrelevant. Update these tests to use the `noStrict` flag.

Other tests concern language semantics that are only valid in strict
mode, but the mechanism for enabling strictness is inconseqential.
Update these tests to use the `onlyStrict` flag and remove any redundant
`use strict` directive prologues contained within.

Still other tests are valid both within and outside of strict mode.
In keeping with the majority of other tests, do not specify any
restrictions on the environments in which these tests may be run.

The `$PRINT` helper function has no effect on test behavior. The
following tests use it to report assertion outcomes (and as a result
will fail silently):

- test/language/function-code/S10.2.1_A4_T2.js
- test/language/function-code/S10.2.1_A5.1_T1.js
- test/language/function-code/S10.2.1_A5.1_T2.js
- test/language/function-code/S10.2.1_A5.2_T1.js

Remove the function definition and all references within tests. Update
tests that use it as an error reporting mechanism to instead use an
appropriate `assert` helper function.

In neglecting to assert the type of error thrown (or that any error was
thrown at all), these tests cannot fail. Refactor the tests to use the
`assert.throws` helper method, which takes these details into
consideration.

This function is equivalent to `$ERROR` (which is automatically included
in test environments). Remove the harness file that defines the
function, remove references to the file from test `includes` lists, and
update scripts to instead invoke the `$ERROR` function.