stream: handling invalid stream arguments in `stream.pipeline()`

[Renegade334]

A few "what goes where"-related inconsistencies with stream.pipeline(). Validation of stream objects is very hit-and-miss:

Passing this:	as this:	should do this:	and does this:
Non-readable Node stream	source	Should be rejected.	❌ Passes validation. Gets passed to Duplex.from(), resulting in a write-only Duplex. The pipeline will never receive any data.
	transform	Should be rejected.	✔️ Fails validation.
	destination	Should be accepted.	✔️ Passes validation.
Non-writable Node stream	source	Should be accepted.	✔️ Passes validation.
	transform	Should be rejected.	❌ Passes validation. Fails asynchronously at runtime: when the previous stream in the pipeline emits data, raises a TypeError due to attempting to call missing Writable methods.
	destination	Should be rejected.	❌ Same as above.
ReadableStream	source	Should be accepted.	✔️ Passes validation.
	transform	Should be rejected.	✔️ Fails validation.
	destination	Should be rejected.	❌ Passes validation. Fails asynchronously at runtime: raises a TypeError due to attempting to call the missing getWriter() method.
TransformStream	source	Undocumented, but should be accepted.	✔️ Passes validation.
	transform	Should be accepted.	✔️ Passes validation.
	destination	Undocumented, but should be accepted.	✔️ Passes validation.
WritableStream	source	Should be rejected.	❌ Passes validation. Gets passed to Duplex.from(), resulting in a write-only Duplex. The pipeline will never receive any data.
	transform	Should be rejected.	✔️ Fails validation.
	destination	Should be accepted.	✔️ Passes validation.

These should probably be validated consistently.

Other observations:

• The docs should specify that TransformStreams are valid source and destination streams, as well as valid return values.
• The transform validation error message doesn't specify which parameter failed validation, which is a pain in terms of debugging. Its counterparts in stream.compose() pass the parameter name to the error constructor as streams[n], which would be a fairly straightforward improvement.

[efekrskl]

I'm working on this.

On a positive note, TypeScript types seem not to have such inconsistencies.