Make string building a bit more efficient for NonEmptySeq

[danicheg]

String building from Iterator is about 5% more efficient than from Seq. Benchmarked on 2.13, it should be the same on 2.12, I suppose.

[johnynek]

I really appreciate PRs like this.

I'd love to see if we can search the code (or even potentially eventually use wart remover or something) to look for cases when we have .map that builds a new structure that is thrown away.

The pattern of seq.iterator.( ops ).(build result) is often a better pattern than seq.(ops).

It would be awesome if we could somehow use scala 3 metaprogramming to communicate these kinds of rewrites to the compiler.

[satorg]

It is not a concern regarding this PR – I'm pretty sure it is good to go, thank you @danicheg !
But rather an attempt to spin-off more generic discussion.

@johnynek ,

I'd love to see if we can search the code (or even potentially eventually use wart remover or something) to look for cases when we have .map that builds a new structure that is thrown away.

The pattern of seq.iterator.( ops ).(build result) is often a better pattern than seq.(ops).

Agree that it would be really nice, but that raises a question in regards to non-empty collections. Should we consider a new abstraction of non-empty iterator for that? For example:

val nel: NonEmptyList[Int] = ???

// works because NonEmptyList#Map returns NonEmptyList
nel.map(<whatever>).reduce(<whatever>) 

// does not work because `NonEmptyList#iterator` returns just `Iterator`
// thus, we lose the non-emptiness guarantee here.
nel.iterator(<whatever>).toList.reduce(<whatever>)