fix ReadableStream.from() cancel behavior per WPT spec

[anonrig]

This change fixes 3 edge cases in ReadableStream.from cancel behavior.

1. When iterator's return property exists but is not callable, cancel now rejects with TypeError.
2. When return rejects, the rejection is now propagated directly without calling throw on the iterator.
3. When return fulfills with a non-object, the error is now properly propagated.

[github-actions]

The generated output of @cloudflare/workers-types matches the snapshot in types/generated-snapshot 🎉

[jasnell]

The plan is to eventually add a default-on date for pedanticWpt, we're just not there yet.

[jasnell]

I believe this should be addressed in the impl of return_(...) more generally rather than being specific to ReadableStream.from().

[jasnell]

It would be good to update the generator tests directly in addition to just enabling the streams related wpts.

[anonrig]

@jasnell please take a look, i've addressed your review

[jasnell]

This is a bit non-obvious. The variable is called ...NotCallable but it's being set with a call to isNullOrUndefined. This could use a bit more explanation to be clearer explaining that if return is not a function, maybeReturn will be kj::none and that the additional check here is just an indicator of whether the property actually existed or not (using a has(...) might be better if we keep this check to avoid the additional handle creation?).

Also, the fact that the return property is being looked up twice is rather unfortunate, especially given that the lookup could have side effects in some edge cases and subsequent accesses are not necessarily always guaranteed to yield the same value.