Todo items
----------

* state more clearly the null-termination property of strict ByteStrings
    - strings created via mallocByteString, generate or create will be
      null terminated. Strings created with slices, won't be.

* would it make sense to move the IO bits into a different module too?
        - System.IO.ByteString
        - Data.ByteString.IO

* pack/unpack -> fromList/toList ?
        - Don sez: i don't like it. pack/unpack is culturally significant :)

* can we avoid joinWithByte? 
        - Hard. Can't do it easily with a rule.

* think about Data.ByteString.hGetLines. is it needed in the presence of
    the cheap "lines =<< Data.ByteString.Lazy.getContents" ?

* unchunk, Data.ByteString.Lazy -> [Data.ByteString]
    -  and that'd work for any Lazy.ByteString, not just hGetContents >>= lines

* consider if lazy hGetContents should use non-blocking reads. This should
    allow messaging style applications (eg communication over pipes, sockets)
    to use lazy ByteStrings. I think that at the moment since we demand 64k
    it'd just block. With a messaging style app you've got to be careful not
    to demand more data than is available, hence using non-blocking read
    should do the right thing. And in the disk file case it doesn't change
    anything anyway, you can always get a full chunk.

* think about lazy hGetContents and IO exceptions
