Buffers aren't retained when stream closes.

The current write path for sending data is optimized to minimize
data copies. A result of this is in SPDYStream _readData, for
fixed buffers (rather than streamed data), a non-copy NSData shard
is returned. This maps over a portion of the buffer SPDYStream owns.
Once SPDYStream goes away -- finishes writing, errors, etc -- that
buffer is no longer valid.

From _readData on, no copies are made, yet the data may get queued
for a while in SPDYSocket in the SPDYSocketWriteOp structure and its
associated queue. This could happen if other operations are queued in
front, or if the write buffer is particularly large on a particularly
slow network. Eventually we'll get to the CFWriteStreamWrite call and
tell it to consume data that may have been released.

This change is the smallest one possible and just makes a copy of
SPDYStream's data at _readData time. This is less efficient. I'd like
to revisit this implementation once we prove this is in fact the issue
causing write crashes and look at better buffer management. It would
require changes to the delegate interface between the stream, session,
and socket, as it is currently byte-array-based.
Avoid memcpy but still retain write buffer.

This change maintains the "no copy" semantics but retains the original
buffer using the objc runtime. When the write completes, the original
buffer is released.
Merge pull request #72 from kgoodier/fix/socket-write-crash

Fix crash when write buffer is not retained