Incorrect, or at least highly confusing, wording regarding `BufRead::lines` iterator / in the “File I/O-`read_lines`” example

The sentence introduced (alongside many good changes) in #1679 (cc @pringshia) that

We also update read_lines to return an iterator instead of allocating new String objects in memory for each line.

https://doc.rust-lang.org/nightly/rust-by-example/std_misc/file/read_lines.html

is wrong or at least highly confusing. I would understand this as claiming that the need for creating a new allocation for each line (for the Strings) is avoided, which is certainly not the case. The only thing that is avoided is

• the Vec's allocation for holding all the Strings
• the need to keep multiple Strings in memory at the same time (so at the end, the allocator might decide to re-use some/most of the memory)
• (and of course, the memory consumption of the initial String holding the whole file, from read_to_string, is avoided in the improved version of the code, but that's already mentioned in a separate sentence anyways)

Also, I fell in general, there could be a better explanation of what kind of efficiency is gained. The main gain here, in my view, is keeping memory consumption low; to more effectively improve run time it would be necessary to avoid creating all those Strings at all. There also seems to be the possibility that readers interpret this code as optimal in some sense. This already got better by no longer calling it “efficient method” but just “more efficient method”, but at least a remark that there are ways to become even significantly more efficient – at least in use-cases that admit re-using a String buffer – could be useful.

This issue came up during / is motivated by, the discussion in https://users.rust-lang.org/t/why-using-the-read-lines-iterator-is-much-slower-than-using-read-line/92815

Start with the File I/O “read_lines” example at the linked documentation page and review the sentence about returning an iterator. Revise the explanation so it accurately describes the memory savings and does not imply that per-line String allocations are avoided. Done means the example clearly distinguishes memory consumption from runtime efficiency.