stream: corrections to source normalization - #63416

• Arrays, as special cases of sync iterables, have lower precedence than async iterables (and protocol objects) in async normalization operations.
• Sync iterables should be normalized synchronously in async normalization operations, ie. they may not contain nested async iterables (continuation of stream: minor stream/iter implementation edits #63132).
• Similarly, sync toStreamables should not be allowed to return async sources.
• No explicit rejection is required for async patterns in fromSync(); doing so may exclude objects with both sync and async functionality (eg. objects with both [Symbol.iterator] and [Symbol.asyncIterator] properties). The spec text seems to suggest that objects with a valid sync pattern should be accepted here even if they also have an async pattern, but could do with some clarity.
• In from(), normalise the object returned by toAsyncStreamable directly, not the return value of its Symbol.asyncIterator method: firstly, the async iterator returned by the Symbol.asyncIterator method is not itself obliged to have a Symbol.asyncIterator method, and secondly, the result could in theory be any valid from() source, not just an async iterable.
• Use isUint8ArrayBatch for the from()/fromSync() fast paths.

Note that as things stand, some of the from() cases throw validation errors synchronously (eg. fromSync({ [toStreamable]() {} })) whereas the majority only throw validation errors at the point of iteration. AFAICT, the latter behaviour is what is compliant with the spec, but I haven't touched these for now.