Write queue after connect windows

Walking through the logic...

`uv_pipe_write` (which is called by `uv_write`) always sends a `NULL` `send_handle`, so all that matters is if `nbufs != 1`. Though the docs give an example of how to send `nbufs > 1` example. This seems to have two issues:

1. Incorrect documentation on the capabilities of using `uv_write` on pipes in Windows.
2. Why sending `nbufs == 0` returns `ERROR_NOT_SUPPORTED`? Seems that since there's technically no work to be done that it should just return immediately.

---
On the side, there's a logic flaw in `uv_write` in `src/win/stream.c`. Take the following snippet:
```c
  err = ERROR_INVALID_PARAMETER;
  switch (handle->type) {
    /* case UV_{TCP,NAMED_PIPE,TTY}: */
    default:
      assert(0);
  }

  return uv_translate_sys_error(err);
```
Since `default: assert(0)` there's no sense in setting `err = ERROR_INVALID_PARAMETER;`

This same logic flaw exists in `uv_write2`

---

`uv_pipe_write2` is only called by `uv_write2` in `src/win/stream.c` and passes `send_handle`. Docs say:
> _send_handle_ must be a TCP socket or pipe, which is a server or a connection (listening or connected state). Bound sockets or pipes will be assumed to be servers.

In this case the check effectively becomes `if (nbufs > 1)`. The docs say about `uv_write2`:
> Extended write function for sending handles over a pipe. The pipe must be initialized with ipc == 1.

So I'm not sure why using `uv_write2` when `nbufs == 0` is fine, but not `uv_write`. And, again, there's the issue that only 1 `uv_buf_t` can be written at a time to a pipe on Windows.