Partial mitigation for lock-ups on long lines
Partial mitigation for lock-ups on long lines

Partly address the lock-ups reported in this thread:

    https://github.com/wincent/ferret/issues/43

By commenting out various parts of the code I was able to establish that
Vim itself is able to chew through the output pretty fast, the `strlen`
and `match` calls are almost free, and most of the cost seems to be in
the `strpart` calls.

So, this commit refactors those calls away, replacing them with `split`.
This still isn't perfect -- Vim is slow/laggy to respond during
processing -- but at least it doesn't lock up.

Other notes based on what I logged:

- `a:msg` varies from run to run. For example, I had runs in a small
test directory with some files with huge lines in them where I got less
than 10 messages in all, some as long as 116 million bytes long and
others as short as 348 bytes. Most but not all of these contained at
least one newline. Compare that with other runs where I got as many as
30 messages, ranging from 348 up to about 90 million.
- Many `a:msg` have multiple lines in them; I saw small number like 3 or
4, ranging right up to 79 or 84.

I think I can optimize this further but this is a good start.

wincent/ferret