Address chained proxy streams fully

[TartanLlama]

There appear to be several bugs with proxy TransformStreams (see #1259). We should do a full look into the process and ensure we clean up the behaviour and optimizations.

The shortcutting optimization that is in place is very targeted, but sometimes fires when it shouldn't and sometimes doesn't fire when it should. The way it is set up and triggered is very fragile. Unfortunately, because of how it crosses our code, StarlingMonkey, and SpiderMonkey, it's difficult to truly address all of the fragility

The biggest problem I see is that there is tracking for when a proxy TransformStream is used as a body at some point, but not tracking for if a given read is due to attempting to send the body via a hostcall. So you can, for example, try to read the contents of a body that is represented with a proxy TransformStream using .text() or getReader().read() and it does the wrong thing, because it sees "oh, this proxy is used as a body somewhere, so you don't actually want me to do a read, you just want me to trigger a body_append hostcall so that the upcoming send operation works". But that's not what we do want in those cases, in those cases, we actually do want to do a regular read of the body data into the JavaScript world, and I don't see an easy way to bolt that context into the JS SDK because it's all just based on regular old ReadableStreams.

[TartanLlama]

Also, we do other things based on whether requests are streams or not, such as sending the body with Transfer-Encoding: chunked.

I think maybe some of this can be fixed by making sure that "is this thing backed by a NativeStreamSource" walks through the potentially linked list of proxies everywhere that this is handled.

[TartanLlama]

Issue #1275 is also caused by this