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'

Implement suggested modification to naming scheme.

Files whose name ends in `_.js` are not themselves valid Test262 tests
and should not be interpreted as such by test runners.

---

Because the tests in this patch concern declaration *instantiation*,
care has been taken to avoid asserting binding values following
evaluation. Because a given module's dependencies are evaluated prior to
the module itself, this is only observable in modules which import their
own bindings.

A separate patch dedicated to the evaluation of module code asserts the
behavior of bindings following evaluation.

---

For tests that concern the creation of a module namespace object, this
patch relies on the semantics of the `in` operator. The `in` operator
uses the [[HasProperty]] internal method and avoids testing unrelated
semantics concerning binding resolution. Those semantics should be
explicitly asserted with a separate set of tests dedicated to that
purpose.

---

One test case which is notably missing is error resulting from a cycle
due to an `import` declaration (under the current file naming scheme,
such a test might be named `instn-named-err-circular.js`). Due to the
recursive nature of ModuleDeclarationInstantiation, it is not
technically possible for a circular request to be found in step 12.c.i.
Cycles rely on at least 2 `export` declarations, and because these are
resolved *before* imports, any cycle would trigger failure prior to step
12.c.

---

One aspect of *module* resolution that makes ordering observable is the
fact that resolution can fail in two distinct ways (i.e. with a
SyntaxError or with a ReferenceError). This patch includes tests that
leverage this detail in order to assert that modules are resolved in the
correct sequence.

However, from the perspective of the ECMA-262 specification, the
ordering of *export* (e.g. binding) resolution is not observable. This
is due to restrictions on the grammar, where each export is independent.
When *export* resolution fails, it does so with instances of SyntaxError
alone, precluding the above strategy.

So while ModuleDeclarationInstantiation resolves the exports of the
module's dependencies in the following order:

1. "Indirect" exports, e.g.
   - `export { x } from './y.js';`
   - `export { x as z } from './y.js';`
   - `import { x } from './y.js'; export { x };`
2. "Star" imports
   - `import * as ns from './y.js';`
3. "Named" (my word) imports
   - `import x from './y.js';`
   - `import { x } from './y.js';`
   - `import { x as z } from './y.js';`

Intentional failures cannot be used to discern resolution ordering.