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 ?  
Here is the problem: why do you want to do that? Even though the client graft has a pipe method, it's not supposed to be called by applications (or just for debugging). That graft instance is piped into a client (ws, spdy), which is a Writable (https://github.com/GraftJS/graft/blob/master/lib/client.js#L33).

However, this works, so little worries for this test.