Editorial: simply context preservation logic for generators

[nicolo-ribaudo]

This PR is editorial-only, and changes nothing observable about how the proposal handles generators.

Rather than storing the initial generator context in an internal slot in the generator itself, with this PR we snapshot/restore across yield and yield* operations (for yield*, restoring it after each call to the inner iterator). This has a couple advantages:

• the spec diff is generally smaller (note: a large part of the diff is in package-lock.json because I had to update ecmarkup. The actual diff is +104 -278).
• it matches the mental model that many of us have in the generator-related discussion, where we say that the context "is preserved across yield"
• it will make it simpler to write the spec for https://github.com/tc39/proposal-async-context-disposable, since that proposal will actually need to save/restore across yield rather than using the initial generator context

@andreubotella since you originally wrote this part of the proposal spec, what do you think about this editorial change?

[andreubotella]

Would it make sense to change the Yield() spec operation instead (or perhaps both GeneratorYield() and AsyncGeneratorYield()), since there are spec algorithms that call it? For Await(), its behavior is defined in terms of PerformPromiseThen, which already handles the context propagation.

[nicolo-ribaudo]

Both GeneratorYield and AsyncGeneratorYield are currently used in many more places for internal spec algorithms, where we do not actually want to save/restore, like String.prototype[Symbol.iterator]().next

[nicolo-ribaudo]

I opened tc39/ecma262#3663. If we go with the second proposed approach in that issue, than we can move some of the handling inside the Yield AO.

[jridgewell]

Nice. Now for using we just need to update AsyncGeneratorYield/GeneratorYield to restore the previous binding.