Filtered namespace support for static imports&re-rexports

[caiolima]

This PR is a joint work from me and @nicolo-ribaudo.

It adds support for syntax and semantics of import {prop1, prop2} as ns from "mod", that will generate a namespace object with only exports selected in the braces. We are calling them filtered namespace, and there's support for static imports import [defer] {} as ns from "mod", and support for re-exports export [defer] {...} as ns from "mod".

For import {prop1} as ns from "mod", ns is a new object declared locally in the module that uses the { … } as ns syntax, rather than being shared across different importers that use the same keys. It avoids a complex cache keyed on the sorted list of names, and it also satisfies some requirements we've got from TG3's feedbacks.

Aliasing (import { foo as bar } as obj) is not supported because the import names do not introduce bindings, so there is no conflict risk.

TODO:

• Validate names in import {valid_export, non_valid_export} as ns from "mod"
  • Validate names in export defer {valid_export, non_valid_export} as ns from "mod", only if ns is imported
• Add the dynamic import option for this

[nicolo-ribaudo]

I noticed that step 1 of InitializeEnvironment calls ResolveExport on all of its re-exports, thus initializing the export { ... } as ns binding before that it's created.

I'll change the initialization lazyness to only apply to export defer { ... } as ns and not export { ... } as ns.

[nicolo-ribaudo]

Uhmm there is actually a larger problem. When we have a cycle like this:

// entrypoint
export defer { x } as ns from "./dep";
import "./dep";

// dep
import { ns } from "./entrypoint"
export let x = 1;

We first run InitializeEnvironment on dep. As part of its initialization it resolves ns from entrypoint, and at this point it would need to initialize it inside entrypoint. However entrypoint.[[Environment]] does not exist yet, so there is nothing to initialize it into.

[nicolo-ribaudo]

I pushed a commit that solves the first problem but not the second. Fixed

[caiolima]

Those last 2 changes LGTM.

[caiolima]

Regarding this TODO: Figure out where to call [EnsureResolvableBindings](https://github.com/tc39/proposal-deferred-reexports/pull/29#sec-ensureresolvablebindings). Not here, as this is meant to be free from side effects..
What if we place the Resolve biding on the InitializeEnvironment of the module that it is importing optional bindings? We could do it while iterating on module.[[ImportEntries]]. There we can get all [[OptionalIndirectExportEntries]] that are being imported and apply EnsureResolvableBindings.

[nicolo-ribaudo]

@caiolima Fix validation of names of deferred filtered re-exports integrates this PR with #34

[caiolima]

@caiolima Fix validation of names of deferred filtered re-exports integrates this PR with #34

Thanks for updating it!