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