unix: try to write immediately in uv_udp_send
test: fix watcher_cross_stop

It's possible that recv_cb_called is bigger than the number of sockets,
because if all sends succeed the recv callback is called twice: once
with the actual data, and another time with 0.
doc: clarify why we don't use SO_REUSEADDR for TCP on Windows
unix: remove incorrect assert

After 41891222bc landed it's possible that uv__udp_sendmsg is called
even if there are no pending write nor write completed requests:

1. User calls uv_udp_send and the request is sent immediately. The
   request is the added to the completed queue and we 'feed' the uv__io
   handle so that we process the completed request in the next
   iteration.
2. User calls uv_udp_send again but the request is not completed
   immediately, so it's queued in the write_queue.
3. The uv__io handle gets a UV__POLLOUT event and uv__udp_sendmsg is
   run, which completes the send request and puts it in the
   write_completed_queue. Afterwards, uv__udp_run_completed is executed
   and the write_completed queue is drained.
4. At this point, the uv__io handle was made pending in step 3, in
   uv__udp_sendmsg, but we no longer have requests to write or to complete,
   so we skip processing.
doc: clarify the return value of uv_default_loop
openbsd: avoid requiring privileges for uv_resident_set_memory
unix: guarantee write queue cb execution order in streams

The problem was that the canceled write callbacks
were being called before the already written callbacks, even
though they were queued after them.
return error codes instead of failing asserts
return error EMEM instead of abort in uv_fs_poll_start
return EINVAL on invalid type in uv_accept
return EINVAL in uv_listen
make pthread_mutex_init reentrant