Because these files contain syntax errors, the code they contain is not
intended to be executed, and the runtime semantics are therefore
irrelevant. Simplify the files by removing the unnecessary code.

Early errors may result from parsing the source text of a test file, but
they may also result from parsing some other source text as referenced
through the ES2015 module syntax. The latter form of early error is not
necessarily detectable by ECMAScript parsers, however. Because of this,
the label "early" is not sufficiently precise for all Test262 consumers
to correctly interpret all tests.

Update the "phase" name of "early" to "parse" for all those negative
tests that describe errors resulting from parsing of the file's source
text directly. A forthcoming commit will update the remaining tests to
use a "phase" name that is more specific to module resolution.

This pattern makes expectations more explicit by making test files more
literal.

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'

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.