Fix regex to identify matches in content search response

[Dananji]

Related issue: #564

[cjcolvar]

I tried testing this locally by converting the Gatsby test data into a VTT (attached as Gatsby.vtt.txt since I had to change the extension to get github to attach it), loading that into Avalon, then testing within ramp. Searching worked as expected for all of the test cases in this PR, but I found a couple issues:

• Searching 'invited' only shows one result in ramp when the content search is returning two (the second being 'invited-they')
• Searching 'dr eckleburg who' or 'went there they' will match correctly but remove the remainder of the cue text

It seems like Ramp is trying really hard to mimic the behavior of Avalon's content search and is doing a pretty good job at it, but I'm afraid of Ramp having to keep up with changes if Avalon changes how it's content search works. I'm wondering if instead of trying to match exactly like how the content search matches Ramp tries to replace the match text entirely with what comes back from the content search and then adjusts the match tags as it sees fit. This approach relies more on the content search which will probably have it's own issues.

If the two issues I saw can be easily fixed then I think this implementation might be good enough for now. If we run into too many edge cases then we may want to consider trying the replacement approach, but I'm hoping that can wait until after Avalon 7.8.

[cjcolvar]

I retested and the two issues are resolved for me! 🎉
I am seeing console logging when a query has a single character after a space. It is still matching and highlighting when there is a valid match like "night I" so I'm not sure if this is really a problem or not.

Error building RegExp for query:  night i
Error building RegExp for query:  who h
Error building RegExp for query:  automobiles w
Error building RegExp for query:  automobiles which b

[Dananji]

These console logs are related to the error I mentioned where, the function building the regular expression bombing when it is called with intermediate queries.

This doesn't impact search within functionality as far as I know. It is just the handling of intermediate states of the search query when it is typed in.