Add option not to destroy duplex stream when either the source or sink iterable completes

(First of all, `stream-to-it` and `it-pipe` are amongst my favourite NPM packages: My code would've been really complicated had you not made these packages available, so thank you so much!)

I'm implementing a WebSocket-based protocol using [`ws`](https://www.npmjs.com/package/ws). `ws` offers a duplex stream to communicate with the peer and I'm wrapping that stream in a "duplex iterable" (generated by `duplex()`), which I pass to `it-pipe`.

The code mostly works as expected, but I'm running into two related issues:

- If there's a `break` in the loop, Node.js would call `duplex.destroy()`, [which will cause `ws` to close the connection abruptly](https://github.com/websockets/ws/issues/1811).
- If the duplex' sink completes normally, Node.js would call `duplex.end()`, which will cause `ws` to close the connection normally -- Even if we're waiting for messages from the source. For example, the protocol I'm implementing sends messages that must be acknowledged by the peer, so if we're done sending messages we should still keep the connection open to receive outstanding ACKs.

I think both issues could be solved if `duplex()` supported an option that wouldn't call `destroy()`/`end()` on the underlying stream (maybe as a pass-through stream). That'd allow me to do something like this on the server:

```javascript
const wsDuplex = WebSocket.createWebSocketStream(ws);
try {
await pipe(loadMessages, duplex(wsDuplex, {allowClosing: false}), processAcknowledgements)

// If we get to this point, processAcknowledgements() must've ended the loop
ws.close(1000, 'All good')
} catch (err) {
ws.close(1008, 'Something went wrong')
}
```

(`duplex.end()` will still be called when the connection is closed. OTOH, the example above is overly simplified: I'd probably have to use an `AbortableController` to signal the source of the duplex iterable when the client closes the connection.)

Thoughts?