SI-8015 Count lines by EOLs

Source lines were counted by "line break chars", including FF.
Clients of `pos.line` seem to all expect the ordinary line num,
so that is what they get.

Unicode processing now precedes line ending processing.
SI-8015 Unprintables in messages

The line content to display should include the whole line,
inclusive of embedded line breaks, and any control chars
should be displayed in unicode escape.
SI-8015 Carat => Caret

Just a diamond in the rough.

Wikipedia warns against confusing it with "carrot."

The first word should really be pronounced as the garage phrase,
"Where's the car at?" and the second like "beret."
SI-8015 Refactor per code review

Make an obscure private def local and rename it usefully.

If you really must have similar functions in the API
(to detect line breaks and EOL), at least make them DRY.
SI-4370 Range bug: Wrong result for Long.MinValue to Long.MaxValue by Int.MaxValue

Fixed by rewriting the entire logic for the count method.  This is necessary because the old code was making all kinds of assumptions about what numbers were, but the interface is completely generic.

Those assumptions still made have been explicitly specified.  Note that you have to make some or you end up doing a binary search, which is not exactly fast.

The existing routine is 10-20% slower than the old (broken) one in the worst cases.  This seems close enough to me to not bother special-casing Long and BigInt, though I note that this could be done for improved performance.

Note that ranges that end up in Int ranges defer to Range for count.  We can't assume that one is the smallest increment, so both endpoints and the step need to be Int.

A new JUnit test has been added to verify that the test works.  It secretly contains an alternate BigInt implementation, but that is a lot slower (>5x) than Long.