windows: make uv_shutdown() for write-only pipes work

A couple of issues prevented uv_shutdown() from working correctly with
write-only pipes.

  * The pipe handle wasn't opened with the right permissions, so an
    attempt to probe the state of the write buffer would fail with
    ERROR_ACCESS_DENIED.

  * The pipe flags for child process stdio pipes were always set to
    UV_HANDLE_READABLE and UV_HANDLE_WRITABLE, even in cases where it
    was actually half-duplex.

  * There was no code path that lead to closing the pipe handle if the
    pipe was write-only.
windows/fs: wrap multi-statement macros in do..while block
windows/fs: make uv_fs_open() report EINVAL correctly

Before, when the user passed an invalid paramter to uv_fs_open, libuv
would detect this and call SET_REQ_RESULT to set the result value to -1.
SET_REQ_RESULT then stored whatever error code was returned by
GetLastError(), which would have no relationship to the actual problem,
and might as well be zero.
windows/fs: handle _open_osfhandle() failure correctly

Until now we assumed that _open_osfhandle() would set _doserrno on
failure. This assumption was very wrong in one obvious case, namely when
the CRT file descriptor table would fill up. In that case errno is set
to EMFILE, but GetLastError() returns zero - which makes sense because
it's not a win32 error but rather a CRT problem.
2013.09.06, Version 0.10.16 (Stable)

Changes since version 0.10.15:

* windows: make uv_shutdown() for write-only pipes work (Bert Belder)

* windows: make uv_fs_open() report EINVAL when invalid arguments are
  passed (Bert Belder)

* windows: make uv_fs_open() report _open_osfhandle() failure correctly
  (Bert Belder)

* windows: make uv_fs_chmod() report errors correctly (Bert Belder)

* windows: wrap multi-statement macros in do..while block (Bert Belder)
Now working on v0.10.17
build: remove GCC_WARN_ABOUT_MISSING_NEWLINE

Not compatible with non-Apple gcc builds.  Fixes the following build
error:

    gcc-4.8: error: unrecognized command line option '-Wnewline-eof'
darwin: fix 10.6 build error in fsevents.c

Work around an 'initializer element is not constant' build error in
src/unix/fsevents.c by turning the const int flags into #defines.

Only an issue on OS X 10.6 due to the old compiler it uses.

Fixes #908.

This is a back-port of commit 82f2472 from the master branch.
2013.09.25, Version 0.10.17 (Stable)

Changes since version 0.10.16:

* build: remove GCC_WARN_ABOUT_MISSING_NEWLINE (Ben Noordhuis)

* darwin: fix 10.6 build error in fsevents.c (Ben Noordhuis)
Now working on v0.10.18
windows: remove duplicate check in stream.c

Fixes #937.
unix: set O_NONBLOCK in uv_pipe_open()

Don't rely on the caller to set the O_NONBLOCK flag on the file
descriptor.

Prevents sporadic stalls when the file descriptor is in blocking mode
and exactly as many bytes are read as there are available; in that case,
libuv will try to read again and block.  Node.js was guilty of this.

Fixes #941.
Revert "unix: set O_NONBLOCK in uv_pipe_open()"

It turns out that node.js relies on the blocking behavior of pipes in
some cases, notably when forking worker processes.  Reopens #941.

This reverts commit 8fe4ca686bcb069f670b0381e89c008ca814f8ba.
Merge remote-tracking branch 'origin/v0.10'

Conflicts:
	ChangeLog
	include/uv-darwin.h
	src/unix/darwin.c
	src/unix/fsevents.c
	src/version.c
	src/win/fs.c
unix: sanity-check fds before closing

Ensure that close() system calls don't close stdio file descriptors
because that is almost never the intention.

This is also a partial workaround for a kernel bug that seems to affect
all Linux kernels when stdin is a pipe that gets closed: fd 0 keeps
signalling EPOLLHUP but a subsequent call to epoll_ctl(EPOLL_CTL_DEL)
fails with EBADF.  See joyent/node#6271 for details and a test case.
unix: remove uv__pipe_accept()

It's basically a less advanced version of uv__server_io().  Drop the
former in favor of the latter.
fsevents: fix clever rescheduling

There're could be a situation, where one fsevents handle gets created
and another one is destroyed simultaneously. In such cases
`fsevent_need_reschedule` will be set to 1 twice and reset only once,
leaving handle destructor hanging in uv_sem_wait().
test: relax TTY availability assumptions

test-tty.c currently assumes that a TTY is available to the test runner,
and fails hard if not. This may not be true on some autobuilding
environment, making the build fail as shown in [0].
Instead, let's properly skip the test in such cases.

[0] http://ur1.ca/fr5bd

Signed-off-by: Luca Bruno <lucab@debian.org>
test: relax timing assumption of loop_stop

The loop_stop test makes an implicit assumption about the triggering
timing of a repeating trigger, which may not hold true on slower or
virtualized machines, thus failing the test as shown at [0] and
discussed at [1].
This commit relaxes the assumption, without mandating the exact number
of runs.

[0] http://ur1.ca/fr5bw
[1] https://groups.google.com/d/msg/libuv/5-fNIC7hIAo/yqznDmwHDAIJ

Signed-off-by: Luca Bruno <lucab@debian.org>
test: relax timing assumption of timer_again

timer_again test makes an implicit assumption on the triggering
timing of a repeating timer. However, this assumption may be not
true on slower or virtualized architecture due to delay accumulation,
which may fail the test as show in [0].
This commit makes explicit checks conforming to the asserted behavior.

[0] http://ur1.ca/fr5c4

Signed-off-by: Luca Bruno <lucab@debian.org>