More detailed export statement tracking

[guybedford]

The following would be highly useful for export tracking in cycles for ES Module Shims.

This does not need to be comprehensive by any means, but a best effort approach would make progress for ES Module Shims cycle support.

• exports replaced by a tracking object of statement start, start, end, statement end. Start and end as the start and end of the exported identifier.
• Detecting where possible the local binding name of the export as an identifier. This is useful for local binding references and internal namespace construction. This could be exported similar to the current n field. We should also only export local bindings that are valid identifiers (for example default is not a valid local binding even though it is a valid export).
• Statement end simply based on the next semi-colon at the top-level bracket depth would be fine for most purposes, and useful enough to enable binding injection, even if multiple exports have the same statement end in this model.
• It could even be worth including a field noting if there was possibly executable code between this export and the last. A similar approach for imports would be a step towards TLA rewriting as well, replacing the current shell parse step.

[tommie]

We should also only export local bindings that are valid identifiers

Could you elaborate on what you mean by valid identifiers? I couldn't find an existing function to check that.

Edit: e.g. would you consider "default" a valid identifier, or is that a keyword?

[tommie]

Does the parse() API need to be backwards-compatible, or can this simply change the second element to be an array of objects?