uv: Upgrade to v0.10.23
2014.01.23, Version 0.10.25 (Stable)

* uv: Upgrade to v0.10.23

* npm: Upgrade to v1.3.24

* v8: Fix enumeration for objects with lots of properties

* child_process: fix spawn() optional arguments (Sam Roberts)

* cluster: report more errors to workers (Fedor Indutny)

* domains: exit() only affects active domains (Ryan Graham)

* src: OnFatalError handler must abort() (Timothy J Fontaine)

* stream: writes may return false but forget to emit drain (Yang Tianyang)
src: lint lib/net.js
Merge branch 'v0.10.25-release' into v0.10
Now working on 0.10.26
blog: Post for v0.10.25
test: fix http-many-ended-pipelines server close

The test was calling server.close() without waiting for the server
to have received all the requests. This would cause an ECONNRESET.
test: fix http-incoming-pipelined-socket-destroy

The test was calling server.close() after write on the socket
had completed. However the fact that the write had completed was
not valid indication that the server had received the data.

This would result in a premutaure closing of the server and
an ECONNRESET event on the client.
npm: Upgrade to v1.3.25
doc: fix typo in readline
doc: readline document TTY utils

fix #6933
deps: backport b5135bbc from c-ares repo

Original commit message:

    ares_parse_txt_reply: return a ares_txt_reply node for each sub-string

    Previously, the function would wrongly return all substrings merged into
    one.

fix #6931
net: reset `endEmitted` on reconnect

fix #6908
crypto: throw on SignFinal failure

fix #6963
net: make Socket destroy() re-entrance safe

So that we are free to call socket.destroy() in error event handler.

fix #6769
docs: clarify origin in agent.maxSockets section
blog: Post for v0.11.11
node: do not ever close stdio

Even if stdio streams are opened as file streams, we should not ever try
to close them. This could be accomplished by passing `autoClose: false`
in options on their creation.
deps: backport 883637bd from latest v8

Original commit message:

  VS2013 contains a number of improvements, most notably the addition
  of all C99 math functions.

  I'm a little bit concerned about the change I had to make in
  cpu-profiler.cc, but I spent quite a bit of time looking at it and was
  unable to figure out any rational explanation for the warning. It's
  possible it's spurious. Since it seems like a useful warning in
  general   though, I chose not to disable globally at the gyp level.

  I do think someone with expertise here should probably try to
  determine if this is a legitimate warning.

  BUG=288948
  R=dslomov@chromium.org

  Review URL: https://codereview.chromium.org/23449035

NOTE: Path applied without `cpu-profiler.cc` changes because in our
version it was looking totally different.
dtrace: fix arguments warning

Add enough arguments to `NODE_NET_SOCKET_READ()` and
`NODE_NET_SOCKET_WRITE()` stubs.