Redesign SymbolStore and SymbolProvider

[as-cii]

This PR changes SymbolStore and SymbolProvider so that they're faster when retrieving suggestions and when computing symbols.

Before

The way those two objects previously worked relied on storing symbols and the buffer rows they were contained in: this was a problem in a number of ways, especially after buffer changes where we had to scan through all those symbols to adjust their position according to the aforementioned change (in addition, we were doing this synchronously, blocking the UI thread until we scanned all the symbols).

(~ 350ms, benchmarks performed by writing 3 letters with 500 cursors)

Also, searching into SymbolStore involved a series of queries to selectorMatchesScopeChain which caused some major slowdowns every time SymbolProvider.prototype.getSuggestions() got called.

(~ 150ms, benchmarks performed by searching for cor in benchmark/large.js)

After

With this PR we're changing the way we store symbols (avoiding to index them by buffer row) and computing/scoring suggestions (e.g. locality score, fuzzy score, etc.) as we traverse through lines. This allows us to perform a very minimal bookkeeping on each buffer change while still being fast when retrieving possible autocompletions. Moreover, we now make use of TextBuffer.prototype.onDidStopChanging, so that writing one or ten letters in a row doesn't cause the main thread to stall.

This is how symbols re-computation looks like after these changes:

(~ 46ms, 8x faster 🐎)

When storing tokens, we keep an index of symbols by letter for each buffer row. When retrieving them, we exploit the fact that a symbol needs to start with the prefix's first letter and, therefore, we score only tokens that match that first character.

(~ 53ms, 3x faster 🐎)

Storing that index on a per-row basis has the advantage of not requiring us to deal with the "moving nature" of buffer rows, but forces us to iterate over every single line. Ideally here we may want to build a smarter data structure (i.e. a tree) that indexes letters across rows; on the other hand, though, the array-based implementation has pretty decent performance, and I believe we can avoid the added complexity of introducing an extra data structure for the time being.

Conclusion

Overall, this should allow us to take autocomplete-plus out of the multi-cursor slowness equation. I still feel like there's room for improvement (e.g. see the across rows index mentioned in the previous section) but I think this should allow us to move forward and deal with other bottlenecks in packages and tokenization.

/cc: @nathansobo @maxbrunsfeld @benogle for 👀

[as-cii]

I am testing for the presence of onDidChangeText here because I couldn't find any other efficient heuristic to determine whether or not atom/text-buffer#126 shipped. This is temporary, though, so it might not be that important.