Restart search in page when new text is found.

This patch is a partial solution to the problem, when DOM was changed and
Find Next In Page fails to show correct results that corresponding to the
current DOM.

For context, some details how Find in Page works:
1. When the user initializes new search RenderFrameImpl::OnFind is called, in
order not to block UI it quickly returns the first result and schedules new full
search task (it's called scoping request in code).

2. The full search task runs and adds all occurrences of the searched text as
markers in DocumentMarkerController. These markers are  presented to the user as
search results.

3. When the user starts FindNext in browser, again RenderFrameImpl::OnFind is
called, it runs search from the place of previous search result and in
TextFinder it's called DocumentMarkerController::setMarkersActive to set the
current result. No new markers to DocumentMarkerController are added.

Current FindNext implementation (TextFinder) uses current DOM and gives correct
results, the problem is that DocumentMarkerController::setMarkersActive silently
fails to add marker when it receives a search result in content that was added
after full search in 2.

The proposed solution in this patch:
1. When DocumentMarkerController::setMarkersActive fails to find marker that
corresponds to a current FindNext result (that means that it's new part of DOM,
that was loaded after the initial full search), it adds this result range as
active marker and returns false to TextFinder.

2. TextFinder receives information that the new text found, it stores restore
point to the following full search (so search will continue from the same
place). And returns to RenderFrameImpl activeNow=false.

3. RenderFrameImpl receives that activeNow=false restarts full search (in a
separate task, the same as with original search).

This patch doesn't solve all problems, namely
1. In order to see new results the user should use FindNext till new results are
found.

2. If something is removed from DOM, new search is not restarted (it's hard to
find out about this from DocumentMarkerController), so the user will see
incorrect number of results, but the user will still see correct highlighted
search results in a page (the same behaviour as now).

but it makes problems much less severe.

BUG=2220

Review URL: https://codereview.chromium.org/1605863002

Cr-Commit-Position: refs/heads/master@{#376994}
11 files changed