Editorial: Adjust invalid assertion about [[AsyncEvaluationOrder]]

[nicolo-ribaudo]

Silly mistake by me in #3353, where I translated "[[AsyncEvaluation]] is false" to "[[AsyncEvaluationOrder]] is unset".

That's not true even in trivial cases. If you have module A that depends on module B, and B is async:

• you first import A, which imports B. Once everything is done, B has [[AsyncEvaluationOrder]] set to done
• then with a dynamic import you import B, whose re-Evaluation obviously completes synchronously (because it's already evaluated) but does not have [[AsyncEvaluationOrder]] set to unset.

This is different from the error case, where we can indeed assert that [[AsyncEvaluationOrder]] is unset. That's because in the error case we perform the assertion on what's in the stack, but we push modules to it only after checking that they are not already evaluated.

[guybedford]

LGTM. It might be slightly more revealing to say is ~unset~ or ~done~ here to help understand the cases directly instead of via negation.

[nicolo-ribaudo]

[ready to merge]? :)

[ljharb]

(that's only up to the editors)

[michaelficarra]

And I'm not sure yet whether @syg will want to review this.

[nicolo-ribaudo]

Ping @syg if you want to review this :)

[bakkot]

Ready to land but needs @jmdyck's suggestion pulled in when landing, which we can do.

[github-actions]

The rendered spec for this PR is available at https://tc39.es/ecma262/pr/3613.