Fix a bug where calling p.destroy() on the result of calling
start_program(...) would cause a segfault when p went
out of scope due to out_file/err_file being closed twice.
Update doc-comments to reflect the current year and trait
names now being capitalized.
Change the behaviour of core::run::Program.destroy to
forcibly terminate the program (as suggested in issue #5632)
Make destroy() send SIGTERM and add a new method called
force_destroy() that sends SIGKILL - as suggested by 
@thestinger.
fix index out of bounds error of x86_64 ABI
librust: make `rust run file.rs` past any extra arguments to the compiled program.
auto merge of #5863 : huonw/rust/rust-run-args, r=thestinger

e.g. 
```
$ cat echo.rs
fn main() {
   io::println(fmt!("%?", os::args()));
}
$ rust run echo.rs 1 2 3
~[~"./echo~", ~"1", ~"2", ~"3"]
```
librusti: only use std::rl if stdin is connected to a tty.
auto merge of #5761 : Dretch/rust/murder-death-kill, r=thestinger

As proposed in issue #5632.

I added some new stuff to libc - hopefully correctly. I only added a single signal constant (SIGKILL) because adding more seems complicated by differences between platforms - and since it is not required for issue #5632 then I figure that I can use a further pull request to flesh out the SIG* constants more.
Avoid excessive allocations and copies in iter::to_vec

The foldl based implementation allocates lots of unneeded vectors.
iter::map_to_vec is already optimized to avoid these.
Clarify purpose of NumCast trait
Generate NumCast impls and tests using macros
Add a test to show how NumCast can be used in type parameters
Remove trailing whitespace
Restore Num trait

This restores the trait that was lost in 216e85fadf465c25fe7bc4a9f06f8162ec12b552. It will eventually be broken up into a more fine-grained trait hierarchy in the future once a design can be agreed upon.
Consolidate tests of numeric operations
Remove unnecessary enclosing modules for NumCast impls
auto merge of #5869 : bjz/rust/master, r=graydon

This restores the trait that was lost in 216e85fadf465c25fe7bc4a9f06f8162ec12b552. `Num` will eventually be broken up into a more fine-grained trait hierarchy in the future once a design can be agreed upon.

To contribute to the discussion about the future of Rust's numeric traits, please see issue #4819 and the [wiki page](https://github.com/mozilla/rust/wiki/Bikeshed-Numeric-Traits).

I have also switched to [implementing NumCast using macros](https://github.com/bjz/rust/commit/353ce872e287edf3764ca416d2a8cd8e1f54329b). This removes a significant number of lines of code.
auto merge of #5810 : thestinger/rust/iterator, r=graydon

The current protocol is very comparable to Python, where `.__iter__()` returns an iterator object which implements `.__next__()` and throws `StopIteration` on completion. `Option` is much cleaner than using a exceptions as a flow control hack though. It requires that the container is frozen so there's no worry about invalidating them.

Advantages over internal iterators, which are functions that are passed closures and directly implement the iteration protocol:

* Iteration is stateful, so you can interleave iteration over arbitrary containers. That's needed to implement algorithms like zip, merge, set union, set intersection, set difference and symmetric difference. I already used this internally in the `TreeMap` and `TreeSet` implementations, but regions and traits weren't solid enough to make it generic yet.
* They provide a universal, generic interface. The same trait is used for a forward/reverse iterator, an iterator over a range, etc. Internal iterators end up resulting in a trait for each possible way you could iterate.
* They can be composed with adaptors like `ZipIterator`, which also implement the same trait themselves.

The disadvantage is that they're a pain to write without support from the compiler for compiling something like `yield` to a state machine. :)

This can coexist alongside internal iterators since both can use the current `for` protocol. It's easier to write an internal iterator, but external ones are far more powerful/useful so they should probably be provided whenever possible by the standard library.

## Current issues

#5801 is somewhat annoying since explicit type hints are required.

I just wanted to get the essentials working well, so I haven't put much thought into making the naming concise (free functions vs. static `new` methods, etc.).

Making an `Iterable` trait seems like it will have to be a long-term goal, requiring type system extensions. At least without resorting to objects which would probably be unacceptably slow.
auto merge of #5864 : huonw/rust/rusti-detect-tty, r=graydon

This is a fairly large hack, just passing an extra argument through, and I can't test it at all, since rusti doesn't work here to begin with.