initial stab at API for std::net::tcp
std: pushing existing code in net.rs -> net_ip.rs and re-import/exporting
std: misc cleanup for uv::ll

* tweaked the layout of sockaddr_in6 struct in anticipation of future use
* changed several uv:ll fn signatures to use generics and be more flexible
with ptr types they get passed
* add uv_err_data and a help fn to return it.. packages up err_name and
err_msg info from uv_get_last_error() stuff..
std: export net::ip::format_addr
std: impl for net::tcp::connect
std: tweak uv::ll::write signature and make it generic/more flexible
std: impl of net::tcp::write and make net::tcp::tcp_socket a resource
std: impl for high-level tcp client/request workflow
std: no longer return uv::ll::err_data records from net::tcp

they're changed into a net::tcp::tcp_err_data record, for now. once the
scope of possible tcp errors, from libuv, is established ill create an
err type for each one and return those where they might occur
core: add result::unwrap() .. patch from @nmatsakis
std: change tcp_*_result to use result::result.. flatter!
std: makeing uv::ll::listen/accept use generic params for ptr args

more flexibility..
std: FIXME stub net::ip::ip_addr::ipv6 variant...needs parse/format impl

still need implementation for parsing/output formatting and (perhaps?)
representation (for now, i just followef the ipv4 variant's lead and
am representing it as a tuple of 8x u16).

parsing an ipv6 addr is way more complex than parsing an ipv4 addr, so
i'm putting off an implementation here, for now.

candidate solutions:
- could use getaddrinfo() (exists on both POSIX and windows), but with
incompatible fn signatures.
- libuv has a way to parse an ipv6 string into
a sockaddr_in6, but it also requires a port, so it's probably not aprop
for ip_addr
std: first-pass at a tcp server API, with a basic (non-robust) test

also whitespace cleanup

.. for now, the test just spins up the server and listens for messages,
echoing them back to an output port. there's a "kill" msg that it will
listen for. need to point the tcp client and server test impls at each
other for a loopback server/client test, like how its done in uv::ll

once ipv6 parse/format lands, i can add another test using the entirely
same codebase, but substituting an ip_addr ipv6 varient for the ipv4
varient used in the existing code

still need some other plumbing to get the client/server tests to work
together.
std: change sig of uv::ll::accept, again.
std: tightening up net::tcp, server/client test done, still has races..

.. going to rework the listen() API to be non-blocking.
rt: adding rust_uv_* binding for kernel malloc and free'ing :/

I need these in the context of doing various malloc/free operations for
libuv structs that need to live in the heap, because of API workflow
(there's no stack to put them in). This has cropped up several times
when impl'ing the high-level API for things like timers, but I've decided
to take the plunge and use this approach for the net::tcp module.

Technically, this can be avoided by spawning a new
task that contains the needed memory structures on its stack and then
having it block for the duration of the time we need that memory to be
valid (this is what I did in std::timer). Exposing this API provides a
much lower overhead way to address
the issue, albeit with safety concerns. The main mitigation policy should
be to use malloc/free with libuv handles only when the handles, are then
associated with a resource or class-with-dtor. So we have a finite lifetime
for the object and can gaurantee a free(), barring a runtime crash (in
which case you have bigger problems!)
std: reworking how some net and libuv modules are exported in the rc

.. turns out that, without the export, the modules aren't accessible
outside of the crate, itself. I thought that, by importing some module
into another (nesting it) and exporting from that nested module (which
is, itself, exported from std.rc) that my mod would be in the build
artifact. This doesn't appear to be the case. learning is fun!
std: splitting out tcp server API WIP
std: splitting out tcp server API + tests

- we now have two interfaces for the TCP/IP server/listener workflow,
based on different user approaches surrounding how to deal with the
flow of accept a new tcp connection:

1. the "original" API closely mimics the low-level libuv API, in that we
have an on_connect_cb that the user provides *that is ran on the libuv
thread*. In this callback, the user can accept() a connection, turning it
into a tcp_socket.. of course, before accepting, they have the option
of passing it to a new task, provided they *make the cb block until
the accept is done* .. this is because, in libuv, you have to do the
uv_accept call in the span of that on_connect_cb callback that gets fired
when a new connection comes in. thems the breaks..

I wanted to just get rid of this API, because the general proposition of
users always running code on the libuv thread sounds like an invitation
for many future headaches. the API restriction to have to choose to
immediately accept a connection (and allow the user to block libuv as
needed) isn't too bad for power users who could conceive of circumstances
where they would drop an incoming TCP connection and know what they're
doing, in general.

but as a general API, I thought this was a bit cumbersome, so I ended up
devising..

2. an API that is initiated with a call to `net::tcp::new_listener()` ..
has a similar signature to `net::tcp::listen()`, except that is just
returns an object that sort of behaves like a `comm::port`. Users can
block on the `tcp_conn_port` to receive new connections, either in the
current task or in a new task, depending on which API route they take
(`net::tcp::conn_recv` or `net::tcp::conn_recv_spawn` respectively).. there
is also a `net::tcp::conn_peek` function that will do a peek on the
underlying port to see if there are pending connections.

The main difference, with this API, is that the low-level libuv glue is
going to *accept every connection attempt*, along with the overhead that
that brings. But, this is a much more hassle-free API for 95% of use
cases and will probably be the one that most users will want to reach for.