Suppress the following warning:

  ../../src/cares_wrap.cc: In function ‘v8::Handle<v8::Value>
  node::cares_wrap::SetServers(const v8::Arguments&)’:
  ../../src/cares_wrap.cc:1017:5: warning: ‘uv_ret.uv_err_s::code’
  may be used uninitialized in this function [-Wuninitialized]

Split `tls.js` into `_tls_legacy.js`, containing legacy
`createSecurePair` API, and `_tls_wrap.js` containing new code based on
`tls_wrap` binding.

Remove tests that are no longer useful/valid.

StreamWrapCallbacks is a helper class for incepting into uv_stream_t*
management process.

Originally contributed by @tjfontaine, but modified to be faster and
more generic.

Allocate buffer only if the next one isn't free.

StringBytes::Write now uses new v8 API and also does preliminary check
if the string is external, then will use external memory instead.

When large strings are used they cause v8's GC to spend a lot more time
cleaning up. In these cases it's much faster to use external string
resources.

UTF8 strings do not use external string resources because only one and
two byte external strings are supported.

EXTERN_APEX is the value at which v8's GC overtakes performance.

The following table has the type and buffer size that use to encode the
strings as rough estimates of the percentage of performance gain from
this patch (UTF8 is missing because they cannot be externalized).

encoding  128KB    1MB    5MB
-----------------------------
ASCII       58%   208%   250%
HEX         15%    74%    86%
BASE64      11%    74%    71%
UCS2         2%   225%   398%
BINARY    2234%  1728%  2305%

BINARY is so much faster across the board because of using the new v8
WriteOneByte API.

v8 has a new API to write out strings to memory. This has been
implemented.

One other change of note is BINARY encoded strings have a new
implementation. This has improved performance substantially.

The prototype of v8::Persistent<T>::MakeWeak() has changed. Update the
code in src/ to follow suit.

Before this commit NodeBIO never shrank, possibly consuming a lot of
memory (depending on reader's haste).

All buffers between write_head's child and read_head should be
deallocated on read, leaving only space left in write_head and in the
next buffer.

Commit 0bba5902 accidentally (or maybe erroneously) added node_isolate
to src/node.h and src/node_object_wrap.h.

Undo that, said variable is not for public consumption. Add-on authors
should use v8::Isolate::GetCurrent() instead.

I missed that while reviewing. Mea culpa.

Fixes #5639.

Conflicts:
	ChangeLog
	deps/uv/AUTHORS
	deps/uv/ChangeLog
	deps/uv/src/unix/linux-core.c
	deps/uv/src/version.c
	deps/uv/src/win/timer.c
	lib/url.js
	src/node_version.h
	test/simple/test-url.js

This is only relevant for CentOS 6.3 using kernel version 2.6.32.

On other linuxes and darwin, the `read` call gets an ECONNRESET in that
case.  On sunos, the `write` call fails with EPIPE.

However, old CentOS will occasionally send an EOF instead of a
ECONNRESET or EPIPE when the client has been destroyed abruptly.

Make sure we don't keep trying to write or read more in that case.

Fixes #5504

However, there is still the question of what libuv should do when it
gets an EOF.  Apparently in this case, it will continue trying to read,
which is almost certainly the wrong thing to do.

That should be fixed in libuv, even though this works around the issue.

* uv: Upgrade to 0.10.10

* npm: Upgrade to 1.2.25

* url: Properly parse certain oddly formed urls (isaacs)

* stream: unshift('') is a noop (isaacs)

No functional changes, just one less entry in the LICENSE file.

Wrapped two macros in do {...} while (0) blocks and lined up
backslashes.  Uses up semicolon in contexts where a dangling semicolon
is erroneous.

In cases where there are multiple @-chars in a url, Node currently
parses the hostname and auth sections differently than web browsers.

This part of the bug is serious, and should be landed in v0.10, and
also ported to v0.8, and releases made as soon as possible.

The less serious issue is that there are many other sorts of malformed
urls which Node either accepts when it should reject, or interprets
differently than web browsers.  For example, `http://a.com*foo` is
interpreted by Node like `http://a.com/*foo` when web browsers treat
this as `http://a.com%3Bfoo/`.

In general, *only* the `hostEndingChars` should be the characters that
delimit the host portion of the URL.  Most of the current `nonHostChars`
that appear in the hostname should be escaped, but some of them (such as
`;` and `%` when it does not introduce a hex pair) should raise an
error.

We need to have a broader discussion about whether it's best to throw in
these cases, and potentially break extant programs, or return an object
that has every field set to `null` so that any attempt to read the
hostname/auth/etc. will appear to be empty.