Editorial: Introduce AO combining IteratorStep and IteratorValue

[bakkot]

"IteratorStepValue" isn't a great name, but I'm worried that sticking with IteratorStep will lead to a bunch of confusing documentation/comments, so I didn't want to reuse it.

In the cases which deal with completion records explicitly you might have to think for a second to convince yourself the change doesn't actually affect behavior.

The only 2 remaining uses of IteratorStep are in the elisions in [a, /* hole */, b] = iterable. Ordinarily I'd inline it into those and delete the AO, but I want to update 402 and proposals to use the new AO before doing that.

There are still 8 uses of IteratorValue: 7 in yield*, 1 in the AsyncFromSyncIterator wrapper. yield* could probably use a cleanup too, but not in this PR.

[ljharb]

should all of these have an assertion that next is an ECMAScript language value?

[bakkot]

Eh, I don't think it's necessary. It's not hard to tell given the type of IteratorStepValue.

[syg]

This is great.

[bakkot]

@jmdyck done, thanks (though in a slightly different form, following #3273).

[jmdyck]

Okay. That form isn't defined in 5.2.3.4, but the meaning is pretty clear. (Throw it on the pile for PR #1573.)

[bakkot]

Fun fact: this eliminates 24 of the 28 explicit uses of the ReturnIfAbrupt macro. The remaining 4 are: one in [[Call]] for ES functions, one for [[Construct]] for ES functions, and two in the handling of [a, /* hole */, b] = iterable elisions (almost immediately after each of the two remaining uses of IteratorStep mentioned above).

It's tempting to remove it entirely, and replace #1573 with a direct definition of ? instead of defining it in terms of ReturnIfAbrupt.

[michaelficarra]

I would've just never introduced next, but this is fine.

changes addressed