Refactor core::run in order to address many of the issues...

[Dretch]

...mentioned in #2625.

This change makes the module more oriented around
Process values instead of having to deal with process ids
directly.

Apart from issues mentioned in #2625, other changes include:

• Changing the naming to be more consistent - Process/process
  is now used instead of a mixture of Program/program and
  Process/process.
• More docs/tests.

Some io/scheduler related issues remain (mentioned in #2625). I am not sure how best to address these.

[Dretch]

r? Is there anything I should change? Is this remotely the right thing to do?

[brson]

This looks like a big improvement. Thanks!

I just opened #6436 that implies that there is going to be a lot more churn in core::run in the future. Essentially, all I/O in core is going to need two modes of operation - one using the native blocking APIs and one defering to the scheduler event loop.

[Dretch]

@brson

The names unwrap_input, etc. aren't very suggestive to me, since unwrap usually implies transnferring ownership, and in light of input returning a new Writer, not an fd. Maybe we could call these input_fd or something.

No problem. I will push a new commit.

Is there a reason input is represented as a c_int (presumably an fd) and the others are a *FILE.

I don't really know (I didn't make that decision originally), but I can see a couple of things that might go someway to explaining it:

• they (the std io handles) couldn't all be file descriptors (without changing core::io) because there is a io::fd_writer but no io::fd_reader.
• they couldn't all be *libc::FILE because os::fdopen hard codes the "r" mode.

I am also going to push a commit to fix the test that failed on OS X.

[Dretch]

I rebased due to conflicts... r?

[Dretch]

I just did another rebase to fix the merge issues that bors complained about. r?

[Dretch]

I just did another preemptive rebase. r?

[Dretch]

r?