Clarify `reset()` behaviour when multiple things are being output

See https://github.com/web-platform-tests/interop/issues/614

Let's say I have an encoder that has quite a long latency, e.g. 16 frames.

If we enqueue 15 frames for encoding, call flush() and in output callback, call reset() on the encoder after e.g. the 8th callback, what should happen?

Firefox outputs the 15 frames, the flush() succeeds, and then the encoder is reset, because there's no prose to check that the encoder has been reset in the algorithm that calls the callback. But the description of the reset() method says that callbacks are not to continue (paraphrasing).

The intent might have been to not call the callbacks after a reset, and we should make it explicit if that's the case.

Start with the WebCodecs reset() description and the flush() algorithm that invokes output callbacks, then compare the scenario with interop issue 614. Clarify whether callbacks already in progress must stop after reset(), and update the specification prose and algorithm so the expected behavior is explicit.