Support ReadableStream async iteration

Feature request

Please consider supporting async iteration for an existing native ReadableStream implementation by polyfilling:

ReadableStream.prototype.values
ReadableStream.prototype[Symbol.asyncIterator]

This is related to, but separate from, #1445 (ReadableStream.from). I understand from that issue that core-js does not currently polyfill Streams and that expanding into related Web standards is only planned.

Motivation

Some Safari versions support the for await...of language syntax and provide ReadableStream#getReader, but do not implement ReadableStream.prototype[Symbol.asyncIterator]:

typeof Symbol.asyncIterator;
// "symbol"

typeof ReadableStream.prototype[Symbol.asyncIterator];
// "undefined"

This creates a gap for usage-based legacy builds. Babel correctly preserves for await...of because the syntax is supported, and babel-plugin-polyfill-corejs3 can provide the ECMAScript async-iterator primitives, but there is currently no core-js module it can inject for the missing Web Streams method.

A real-world example is PDF.js, where PDFPageProxy.getTextContent() consumes a ReadableStream using for await...of. The missing method causes a runtime TypeError in Safari even though consuming the same stream through getReader() works:

• https://github.com/mozilla/pdf.js/issues/21557
• https://github.com/mozilla/pdf.js/pull/21558
• https://github.com/mozilla/pdf.js/pull/21559

Possible scope

Would core-js consider a module that augments ReadableStream.prototype only when a native/polyfilled ReadableStream constructor already exists, without attempting to polyfill the entire Streams API?

The implementation could define values({ preventCancel }) in terms of getReader(), including the standard cancellation and reader-lock release behavior, and alias [Symbol.asyncIterator] to values when missing.

If partial augmentation of a Web API is outside the intended scope, would this instead be considered as part of the future Streams support mentioned in #1445?