Previously, CreateImportBinding was only supported for module Environment
Records. Supporting the CreateImportBinding method for declarative
Environment Records will be important for nested |ImportDeclaration|s,
since the declarative Environment Record for the nested block containing
the |ImportDeclaration| will need to allow indirect bindings, too.

Because declarative Environment Records may now have indirect bindings,
the GetBindingValue method of declarative Environment Records now fully
incorporates the logic of the GetBindingValue method of module Environment
Records, and so the module-specific method has been removed.

…ion.

This change means |ImportDeclaration|s are no longer grammatically
restricted to the top level of a module.

It also means |ImportDeclaration|s are no longer grammatically restricted
to |Module|s, and could potentially appear in |Script|s, which is a
problem to be addressed in a follow-up commit.

Note that this change allows functions and blocks to define bindings for
|ImportDeclaration|s, which was not previously possible.

After this change, the [[ImportEntries]] field of Module Record is no
longer used anywhere in this specification.

The top-level ImportEntries of a module are now extracted as part of the
CreateLexicalBindings operation, based on the top-level
LexicallyScopedDeclarations of the module, which now include
|ImportDeclaration| productions in addition to other lexically scoped
declarations like function/generator declarations and let/const variable
declarations.

Though it is possible that another specification might depend on this
field, the only relevant specification that I'm aware of is the WHATWG
Loader spec (https://whatwg.github.io/loader), and while it refers to the
Source Text Module Record in many places, it never makes use of the
[[ImportEntries]] field.

Moreover, I think we should remove this field now rather than allowing it
to persist, because any hypothetical auxiliary specification that relies
on [[ImportEntries]] is likely to be treating top-level import
declarations differently from nested import declarations, and thus runs
the risk of mishandling nested import declarations.

…ings.

Unless this note is wrong, we do not have to worry about import
declarations in eval strings, which is good news because it would be
impossible to determine statically what module identifiers are requested
by a dynamic string of code.

This change means nested modules will be evaluated at the beginning of
their enclosing blocks, if they have not already been evaluated.