highlight search term in viewer by default - edge case handling

[ebenenglish]

As described in #128, there are some slight drawbacks to the current implementation of having the UV IIIF viewer automatically run a search for a user's query term, where ...

1: If the keyword search matches text from the item metadata that is not present in the full text, the UV will display a "No matches were found" message when the viewer loads.

This seems like it will likely be a minor issue, since NewspaperPage objects have very minimal descriptive metadata, and search results will most likely be the result of keyword matches in the OCR field. (NewspaperArticle objects may have significantly more descriptive metadata, but the majority of implementations do not have article-level data.)

2: If the keyword search matches stemmed text from the Solr text field, but not the exact text string in the OCR, the viewer will not be able to display a highlight for the term.

This happes because the code that matches the search term to the JSON word-coordinate file only looks for exact matches (NewspaperWorks::BlacklightIiifSearch::AnnotationBehavior#coordinates). Need to make sure there is robust error handling in this method to deal with this edge case and ensure that the app doesn't throw an error.

(See this commit from BPL's Commonwealth app for example.)