Add socket streams.

[tmccombs]

No description provided.

[jasonwhite]

Referencing EBADF is failing the Windows build.

[jasonwhite]

I'd like to merge this, but the two new files are missing the copyright header. I'm a bit inexperienced with this part of open source, but I think the best approach is to use the same copyright header as the other files and list yourself as the sole author (in the Authors: section). Let me know what you think.

[jasonwhite]

Windows build is failing here now.

[MartinNowak]

Using std.socket as a basis for a new I/O library is bad idea, b/c you inherit all the bad parts (e.g. usage of GC allocated class).
Why not simply write your own socket implementation based on simple file descriptors. There isn't much complexity buried in std.socket.

[jasonwhite]

I agree. This needs to be rewritten to not use std.socket. I merged this because it can be useful in the meantime and I'm not too concerned about breaking things later. I haven't had a need for sockets yet, but when I do I'll probably end up rewriting this.

[tmccombs]

There isn't much complexity buried in std.socket.
It does abstract differences between posix sockets and winsockets and does quite a bit around sockaddr. A thin wrapper around connect for example would require the user to allocate memory for the appropriate sockaddr type, initialize it, and cast a pointer to it to a sockaddr*.

I agree that std.socket should be replaced with something that doesn't depend use GC allocated objects, but I don't think that will be a simple task. I would be happy to help work on it though.

[MartinNowak]

Taking a look at the Handle based io.file.stream would be a good starting point. We also established a few principles like using scattered readv/writev.
I guess the more difficult part is to replace InternetAddress, but that could be done as a second step.

[MartinNowak]

I merged this because it can be useful in the meantime and I'm not too concerned about breaking things later.

Which is OK for a 0.0.8 version, but stability is key for adoption ;). I'd really like to help out more, b/c this library looks a lot like what I want for std.io, but I'm too busy w/ the compiler and related things.
Maybe we can attract some other contributors? There are a handful of existing D socket implementations out there.