Limit the maximum number of highlight markers

[wbinnssmith]

This places a configurable limit on the number of highlights shown across all editors.
In my tests, after creating a selection, scanning a large file (50K+ lines) with a match on each line causes Atom's UI thread to lock up for several seconds at a time.

It doesn't, however, lock up when there are only a few matches across files of that size, as a lot of time is spent creating and managing the many markers that result. Likewise, it seems that editor.scan takes considerably longer when there are matches compared to when there aren't on documents of equal size.

By default, the maximum number of results is limited to 500. On my machine (a 2017-era MacBook Pro), scanning a 50K line document with matches on each line with this limit applied reliably completes in under 80ms, which is well under the threshold for a perceptible delay. I'm definitely open to changing this default, especially if it's smaller :)

This is all implemented by throwing an exception once we've hit our result threshold. It's gross, and
I've tried an early return in the scan callback, but the scan runs to completion either way and we end up doing nothing with results that we spent work on. AFAICT, this is the only way we can terminate the scan early without upstreaming support for this in Atom's native C++ text buffer.

cc @matthewwithanm @captbaritone @sunz7

[danielocdh]

Not sure why this didn't work for me at first, I had to add an empty constructor to EarlyTerminationSignal and then it worked, I'm using windows.

Thank you