RFC/WIP: Move more of jl_uv into julia code

[Keno]

/cc @vtjnash

I'm pretty sure that this breaks the REPL on windows, which is why I didn't push it to master. Anyway, I'm working to replace readline in the REPL anyway, so that shouldn't be an issue soon.

I have a couple more changes in the works that build on this, which I'll push to this branch soon.

This helps #2816

[vtjnash]

this maybe shouldn't be immutable, they tend to be a bit hard to ensure they are rooted properly in the GC (e.g. it may gets copied to the stack in the ccall)

[Keno]

Doesn't need to be rooted (after the ccall), since libuv makes a copy of it.

[JeffBezanson]

I'm not really a fan of all this writing C in julia syntax. C should be written in C. Julia is not supposed to have alloca, and we shouldn't have to call malloc much either. Moving code to julia does not solve anything --- it just taxes the compiler more and adds performance risk. Normally if we can't close, say, 1.2x C performance gaps it's not a problem, but for low-level I/O code it's a deal breaker. It also creates problems with potential struct incompatibilities and ccall mismatches (as in #2901).

[JeffBezanson]

Another way to put it: what matters is (1) API design, (2) performance. That's what we need to be addressing.

[Keno]

I agree with you, of course, though the reason that most of these had wrapper functions in C in the first place is that we didn't used to be able to pass Julia functions as callbacks to C, which we now can, so I saw no point in keeping them in C. I have no problem with moving the contents of e.g. _write! back to C.

[StefanKarpinski]

I would add that we really need to focus on stability – especially for I/O stuff, which has felt a bit rickety ever since the windows merge. My impression is that it's gradually been getting better, but I'm leery of introducing a large amount of churn in the I/O code at the risk of further destabilizing things until what we already have is really rock solid.

[JeffBezanson]

I think what we should do is (1) design the API, (2) starting from what we have now, figure out what layer we need to write in C to best support it. "Best" includes making all ccalls from julia very straightforward.