Add a Libc.File constructor that takes a RawFD

[Keno]

Twice this week, I've came across instances where C libraries wanted
a FILE*, but I only had an FD. Since we have Libc.File, we might as
well have this method too.

[Opening PR to have Appveyor look this over]

[IainNZ]

Hah @mlubin this is very related what I was asking about the other day.

Could be good to mention how to deal with FILE* in the C part of the manual.

[tkelman]

This should really be considered a bug in these libraries... that's a horribly non-portable thing to do.

[Keno]

While working on this I am wondering if the conversion to LibC.FILE steal the file descriptor from the IOStream. The problem I'm thinking off is that it's not clear who should close the stream. If we add a close method to LibC.FILE, then we probably should check it's return value and throw an error. Now, it so happens that the IOStream doesn't really care if the FD is valid when closing, so we could just say "If you create a CFILE from an IOStream, always close the CFILE first", but that doesn't seem great, especially considering the IOStream may be closed by GC. Thoughts? cc @JeffBezanson

[JeffBezanson]

Stuff like this is always pretty ugly. I'm not sure there is a good solution. Perhaps we should not have the method that constructs a FILE from an arbitrary IO.

[Keno]

I'd be fine with keeping convert(::Type{Libc.File}, s::IOStream), but I'm leaning towards you not being allowed to use the IOStream afterwards. If you want other behavior, you can always use Libc.FILE(fd(s), LibC.modestr(s)) (though then we should probably export modestr).

[vtjnash]

This should really be considered a bug in these libraries... that's a horribly non-portable thing to do.

this does seem to have the same issue as malloc/free: you don't know if your library is linked against the same libc as julia, so it seems like this usage may sometimes corrupt the program.

(edit: although, on windows, the same issue also exists for file descriptors since the canonical object is a HANDLE)