libcore: handle trailing newlines more like other languages.

[huonw]

The each_line function in ReaderUtil acts very differently to equivalent functions in Python, Ruby, Clojure etc. E.g. given a file t with contents trailing\nnew line\n and n containing no trailing\nnew line:

Rust:

t: ~[~"trailing", ~"new line", ~""]
n: ~[~"no trailing", ~"new line"]

Python:

>>> open('t').readlines()
['trailing\n', 'new line\n']
>>> open('n').readlines()
['no trailing\n', 'new line']

Ruby:

irb(main):001:0> File.readlines('t')
=> ["trailing\n", "new line\n"]
irb(main):002:0> File.readlines('n')
=> ["no trailing\n", "new line"]

Clojure

user=> (read-lines "t")
("trailing" "new line")
user=> (read-lines "n")
("no trailing" "new line")

The extra string that rust includes at the end is inconsistent, and means that it is impossible to distinguish between the "real" empty line a file that ends ...\n\n, and the "fake" one after the last \n.

The code attached makes Rust's each_line act like Clojure (and PHP, i.e. not including the \n), as well as adjusting str::lines to fix the trailing empty line problem.

Also, add a convenience read_lines method to read all the lines in a file into a vector.

[huonw]

@graydon, I've updated this: added split_char_no_trailing (and split_no_trailing) which act like str::lines. This was easier, and seemed like it would be less surprising in terms of behaviour, than changing split_char and adding split_char_keep_trailing. (And, I noticed some old(?) code in compiletest, which I've converted to use the more appropriate str function.)

Also, I did some experimentation and it seems that it wouldn't be too difficult to convert many of the functions that return ~str into &str in the str library: is it worth me spending my time doing that? (Just checking in case there is a broader plan in terms of rewrites/redesigns.)