Document behavior of Splitter that uses both limit() and omitEmptyStrings()

[cpovirk]

https://stackoverflow.com/q/62026064/28465

Conceivably we could even change the behavior, but that may be more dangerous than it's worth.

[cpovirk]

I see some discussion of this internally. (Search for "Jesse and I are working through the finer details of this change.") However, that was on a mailing-list thread. The actual CL was written much later by someone else, and I don't see discussion there (nor on the linked bug).

On that thread, I see some support for the approach that the poster wants. (And I think I prefer that approach, too.)

Here's what our docs say:

When omitting empty strings, the omitted strings do not count.

The question is why we look for an empty string after the first split, rather than just returning everything after. After all, it's not like we omit empty strings that would be produced at the end of the last token. (At least I don't think so :)) So why should the beginning be different?

(I may have general reservations about omitEmptyStrings() that are clouding my judgment here. But it's been a long time....)

[cpovirk]

(The combination of limit() and omitEmptyStrings() does strike me as a little weird: limit() suggests the data comes in "columns" or a key-value pair. If we then omit empty strings, then that could "shift" a value from one column to another or from the value position to the key position.)

[souradeepmajumdar05]

i would like to work on it @cpovirk