Fix a state machine buglet where the UV_STREAM_SHUTTING flag didn't get
cleared.

This fixes a busy loop by working around a quirk with Linux kernels
<= 2.6.32 where an EPIPE or ECONNRESET error on a file descriptor that
is polled for EPOLLOUT but not EPOLLIN gets reported by epoll_wait() as
just EPOLLERR|EPOLLHUP, like this:

  epoll_wait(5, {{EPOLLERR|EPOLLHUP, {u32=12, u64=12}}}, 1024, 433) = 1

Before this commit, libuv called uv__read() which attempts to read from
the file descriptor.  With newer kernels and on other operating systems
that fails like this:

  read(12, "", 65536)         = -1 EPIPE (Broken pipe)

Which tells libuv there is a connection error and it should notify the
user of that.  On the affected Linux kernels however, the read succeeds
with an EOF:

  read(12, "", 65536)         = 0

Which is subsequently passed on to the user. In most cases, the user
will close the handle and everything is fine.

Node.js however sometimes keeps the handle open in an attempt to flush
pending write requests.  While libuv doesn't officially support this,
unofficially it works...

...except on those older kernels.  Because the kernel keeps waking up
the event loop without setting POLLOUT and because the read calls EOF
but don't error, libuv's I/O state machine doesn't progress.

That's why this commit changes uv__stream_io() to also write pending
data.  While the read() system call doesn't error, the write() system
call will.

Fixes nodejs/node-v0.x-archive#5504.

Changes since version 0.10.10:

* unix: unconditionally stop handle on close (Ben Noordhuis)

* freebsd: don't enable dtrace if it's not available (Brian White)

* build: make HAVE_DTRACE=0 should disable dtrace (Timothy J. Fontaine)

* unix: remove overzealous assert (Ben Noordhuis)

* unix: clear UV_STREAM_SHUTTING after shutdown() (Ben Noordhuis)

* unix: fix busy loop, write if POLLERR or POLLHUP (Ben Noordhuis)

Conflicts:
	src/unix/stream.c
	src/version.c