Editor feedback

[guybedford]

Integrates the feedback from @michaelficarra in #26 (comment).

• EvaluateImportCall step 9.b.i: don't say "is not equal to", just say "is not"; see https://github.com/tc39/ecma262/wiki/Editorial-Conventions#comparisons.
• GetModuleSourceModuleRecord: wouldn't it be more appropriate to name this parameter specifier? Isn't it still conceptually a specifier?
• GetModuleSourceModuleRecord step 5: "is equal to" -> "is"
• Source Text Module Records [[SourceText]] field: "ECMAScript source text" is probably a better type. Also I wouldn't include the optimisation note for hosts.
• Source Text Module Records [[ModuleSource]] field: like the above rows, we should describe when it's expected to be empty
• ModuleSourcesEqual step 2: "is equal to" -> "is"
• The ModuleSource constructor: I don't think this is needed: "will throw an error when invoked, where support for dynamic construction may be added in future"
• "For Module Records that implement a normal completion" -> "For Module Records that return a normal completion"

Where is ModuleSourcesEqual called? Why is it on abstract module records and not just source text module records (or better yet, just an AO) if we know it'll only be called on them?

ModuleSourcesEqual is a helper function that is necessary for performing identity checks within HostLoadImportedModule. Since JS and Wasm modules have independent definitions of this equality, this allows us to implement it for JS, then Wasm can implement it on its own concrete module record, and the HTML spec just needs to call the more general ModuleSourcesEqual function. We would need to migrate keying into ECMA-262 for this to be called from ECMA-262 directly. Removing the helper function pushes out more complexity into HTML, which is an option, but when I started writing this as an HTML function it just fitted much better here.

I don't love the not-a-source enum name, but we can bikeshed that during integration

Sure!