process: fix bug where spinner wasn't called

Apperently there is a case where calling the spinner was required after
passing a callback to nextTick(). This fixes that issue.
tls: _handle.readStart/readStop for CryptoStream

lib/http.js is using stream._handle.readStart/readStop to control
data-flow coming out from underlying stream. If this methods are not
present - data might be buffered regardless of whether it'll be read.

see #4657
path: join throws TypeError on non-string args

lib/path.js:
  - throws a TypeError on the filter if the argument is not a string.

test/simple/test-path.js:
  - removed the test to check if non-string types are filtered.
  - added a test to check if path.join throws TypeError on arguments that
    are not strings.
test: add an "async-hello-world" native addon test
test: modify async native test.js to test for #4820
path: Throw TypeError on non-string args to path.resolve
stream: remove lowWaterMark feature

It seems like a good idea on the face of it, but lowWaterMarks are
actually not useful, and in practice should always be set to zero.

It would be worthwhile for writers if we actually did some kind of
writev() type of thing, but actually this just delays calling write()
and the overhead of doing a bunch of Buffer copies is not worth the
slight benefit of calling write() fewer times.
stream: Return false from push() more properly

There are cases where a push() call would return true, even though
the thing being pushed was in fact way way larger than the high
water mark, simply because the 'needReadable' was already set, and
would not get unset until nextTick.

In some cases, this could lead to an infinite loop of pushing data
into the buffer, never getting to the 'readable' event which would
unset the needReadable flag.

Fix by splitting up the emitReadable function, so that it always
sets the flag on this tick, even if it defers until nextTick to
actually emit the event.

Also, if we're not ending or already in the process of reading, it
now calls read(0) if we're below the high water mark.  Thus, the
highWaterMark value is the intended amount to buffer up to, and it
is smarter about hitting the target.
streams: Pre-emptively buffer readables up to the highWaterMark

Also, this adds a test that guarantees that the ordering of several
push() calls in a row is always preserved in synchronous readable streams
lint