Additionally removed the `arrow-function` feature for
test/language/eval-code/direct/new.target-fn.js as it is not testing
arrow-functions, but they are mentioned in the preamble.

- "CannotSuspendMainAgent" feature was changed to "CanBlockIsFalse" flag
- Move annex-b tests into annex-b directory
- Update variable names in nonshared-int-views.js tests
- Move getReport() call in nan-for-timeout.js to avoid iloop
- Update BigInt constructor to match new semantics (tc39/proposal-bigint#138)

Corrections to sec-web-compat-evaldeclarationinstantiation and sec-web-compat-functiondeclarationinstantiation tests. Fixes gh-1364 (#1509)

Signed-off-by: Rick Waldron <waldron.rick@gmail.com>

A recent change to the specification [1] introduces parse-time errors
for certain usages of `super` within eval code. Modify all tests that
are affected by this change:

- Update the test bodies to accurately enforce the new semantics
- Rename files to better reflect the section of the specification that
  they enforce
- Update test meta-data
  - Change the `esid` meta-data to reflect the location of the relevant
    specification text
  - Remove the `es6id` meta-data as the behavior is no longer relatable
    to that specification
  - Introduce the `features` meta-data in cases where the test file's
    new location no longer reflects all required language features

[1] "Normative: Clarify rules around super inside eval"
    https://github.com/tc39/ecma262/pull/685

* Add tests for prototype realm inference

* Add tests for miscellaneous realm concerns

* Add tests for realm of spec-created Errors

In some cases, Error objects produced by the specification are
observable from ECMAScript code. Among these cases, some are further
differentiated in that they occur outside of any built-in function and
may be triggered through syntactic production directly. The current
realm record is commonly interpreted incorrectly under these
circumstances.

Add tests asserting that the expected realm record is used when
constructing such Error objects.

* Add tests for realm use in ArraySpeciesCreate

* Add tests for function realm retrieval

* Add tests for cross-realm behaviors of Symbols

* Add tests for GetValue and PutValue

* Add tests for realm of spec-created Arrays

In some cases, Arrays produced by CreateArrayFromList are observable
from ECMAScript code. Among these cases, two occur outside of any
built-in function and may be triggered through syntactic production
directly. The current realm record is commonly interpreted incorrectly
under these circumstances.

Add tests asserting that the expected realm record is used when
constructing arrays.

* Add test for spec-created object

* fixup! Add tests for realm of spec-created Errors

* fixup! Add tests for realm of spec-created Errors

* fixup! Add tests for prototype realm inference

* fixup! Add tests for miscellaneous realm concerns

Authored via the following command:

   $ find test -type f -print0 | \
       xargs -0 sed \
         -i 's/^\(\s*\)negative:\s*SyntaxError\s*$/\1negative:\n\1  phase: early\n\1  type: SyntaxError/g'

These tests specifically concern error produced from the global scope,
precluding the use of the `assert.throws` helper function.

* Add missing test for early error

* Add missing test for WithBaseObject

* Improve coverage for `new.target`

* Add test for deletion of SuperReference

* Add tests for `in` keyword restrictions

* fixup! Improve coverage for `new.target`

Closes #572

Introduce tests for new semantics for ES2015 features such as
lexically-scoped bindings. Also add tests for semantics defined in prior
editions of the specification but not yet covered in this test suite.

For each test that asserts the behavior of either "direct" or "indirect"
eval (but not both), introduce an equivalent test for the opposite case.

Some tests asserted behavior for both "direct" eval and "indirect" eval.
Split these assertions across files dedicated for each use case.

Limit tests in `language/expressions/call/` and `built-ins/eval/` to
only assert details that are directly related to the invocation pattern.
Re-organize all other tests within the `language/eval-code/` directory,
further categorizing each as `direct` or `indirect` as appropriate.
Remove the extraneous "executable" flag from those files which carried
it.

This changeset includes tests for early errors and those generated
dynamically by eval. It also accounts for relevant AnnexB extensions.

These tests ensure that the annex B extensions for function declarations
are *not* observed in strict mode code.

Some tests for `eval` assert the equality of key enumeration on the
global object, comparing the ordering when the object is referenced
through eval.

Based on the test bodies and the "info" field in their metadata, these
tests appear to have been written under the mistaken impression that
erroneous creation of an environment record would be observable through
the `this` value.

In reality, the value in such cases resolves to the global object. That
renders these tests redundant and overly complex--none of the
distinctions between each test actually demonstrates a different
behavior.

Remove the redundant tests and introduce three new tests asserting the
correct resolution of the `this` keyword for direct eval code from
within the global scope and from within function scope.

The project's expected frontmatter tag name changed while these files
were under review.

Assert that ImportDeclaration and ExportDeclaration match only the
ModuleItem symbol.

According to the definition of HostResolveImportedModule, it is
acceptable for an implementation to throw a SyntaxError in the event
that a requested module can neither be found nor created:

> If a Module Record corresponding to the pair referencingModule,
> specifier does not exist or cannot be created, an exception must be
> thrown.

In order to reliably detect a SyntaxError in response to the correct
interpretation of the grammar (and not a SyntaxError from an *incorrect*
interpretation of the grammar followed by a failure to resolve the
requested module), the ModuleSpecifier of ExportDeclarations should
describe a valid resource.

- 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

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.

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.

Test case 10.4.2-3-c-2-s verifies that eval can't instantiate variables in the calling context. However, it does not verify that the variable isn't matched to the global context either. Added test case 10.4.2-3-c-3-s to check for this.

- Add missing "var" declarations and noStrict flags
- Add strict mode tests for:
 - arguments-object/10.6-6-3 -> arguments-object/10.6-6-3-s
 - arguments-object/10.6-6-4 -> arguments-object/10.6-6-4-s
- Remove try-finally clean-up code
- Add strict mode compatible tests for eval-code/S10.4.2_A1.1_T*
  - No strict mode compatible files added for eval-code/S10.4.2_A1.2_T*, because it doesn't really make sense in this context.
  - (S10.4.2_A1.1 and S10.4.2_A1.2 should probably be removed, because the tested behaviour is not required by the spec.)
- Split S8.5_A10, S8.5_A4 and S8.1_A3 into declaration (both modes) and assignment tests (non-strict only)

Part of issue #35.