Echoing messages back to the client change how embedded channels in them work.

I ran into this when I was working on something in Aetherboard,
so I put it together in a simplified test case to help debug/fix the issue.

The first new test, ensures that i can embed a writeable into a message,
and then while piping the channel it is sent on,
I should always be able to pipe the writeable into something.
This is with any of the sessions, or even with just 1 graft instance.

The second test, is where I pass a return channel to the server and expect
it to echo the messages back to me.

I expect to be able to pipe the return channel messages in the same way as the
messages are piped on the remote side, or as they are piped directly from the client.

What happens is that the channel attached to the messages that gets echoed back,
can no longer be piped from.

Echoing messages back is actually one of the more common network behaviours,
such as for instance in group chat. When I post a message, I need to wait for it to be
sent back to me to be added into the single stream of conversation.

any hints where to start looking to fix this @mcollina ?  
`msg.writes` on the client is a `WriteChannel`, which you should not `pipe` into anything, it's __reserved for jschan to use__, as all channel are unidirectional. So, the bug here is that we should pop an exception when somebody do that.

If it's Writable, you can't read through it. Not sure if this limit what you can do in Aetherboard, and how we can fix it.

Is it possible to refactor around this issue?