New API for tcp based sockets

Review by @pchlupacek and @fthomas 

Hi guys, I wasn't really happy with the existing API in `nio`, especially for code that needs to alternate between reading and writing to the socket in a particular sequence. This PR introduces a new type, `Connection`, and a `Process[Connection,A]` represents a stream that may read or write to a socket. See [`tcp.scala`](https://github.com/scalaz/scalaz-stream/blob/topic/socket/src/main/scala/scalaz/stream/tcp.scala#L113). 

Here's the logic for an echo server:

```Scala
val echo: Process[Connection,Unit] =
  tcp.writes_(tcp.reads(1024, allowPeerClosed = true)) ++
  tcp.eof ++
  Process.emit(())
```

To actually get a server for that logic, you do:

```Scala
val server: Process[Task, Throwable \/ Unit] = 
  tcp.server(addr, concurrentRequests = 1)(echo).run
```

Here's logic for a chat server (I think):

```Scala
   val server = Process.suspend {
      val topic = async.topic[String]()
      val chat =
        tcp.reads(1024).pipe(text.utf8Decode).to(topic.publish).wye {
          tcp.writes(tcp.lift(topic.subscribe.pipe(text.utf8Encode)))
        } (wye.mergeHaltBoth)
      tcp.server(addr, concurrentRequests = 50)(chat).run
    }
```

Check out [the tests](https://github.com/scalaz/scalaz-stream/blob/topic/socket/src/test/scala/scalaz/stream/TcpSpec.scala#L33). I'd like to get some feedback on this before merging. I anticipate deprecating and then removing the existing `nio` stuff in a future release, and then moving the `nio` specific stuff out of `tcp` and into `nio`, so I want to make sure the `tcp` API handles all the use cases of the existing API.

There seems to be a JDK issue on Mac with `AsynchronousSocketChannel` - it sometimes hangs on close when the socket is read / written concurrently. It does not happen often, but with scalacheck it happens every time. :) The travis build (which uses linux) is passing, though. @pchlupacek I am pretty sure this issue is also present in the existing `nio` implementation and I feel like I remember seeing random hangs on mac in some earlier version of the test suite. Does this sound familiar at all? It seems like the [netty devs may have encountered the same issue with `AsynchronousSocketChannel`](https://github.com/netty/netty/issues/852). I'd love to get to the bottom of it since I know a lot of people develop on Mac.
If the other side disconnects normally, this returns `None`. If the other side dies or shuts down abruptly, `allowPeerClosed = true` allows you to convert the exception you'd get to a `None`. I think having it be by default false (peer closed / broken pipe exceptions get raised) is reasonable, but there are cases where you might want to just treat this as a normal event.

The other reason to have this option is that there isn't a good way in Java to reliably detect broken pipe or peer closed exceptions (Java does not have an exception subtype for these cases). The hack I am using looks at the message attached to the exception. I'd like to keep this logic in one place, rather than forcing everyone who wants to recover from this event implement their own hack.