Fix: Defer re-decorating note when changing search

[dmsnell]

See #1941
See #1982

When we rebuilt the search to return instant results and removed the debounce
on the search filter we exposed an issue with note rendering performance that
ironically made the new instant search slower than the old one in certain
circumstances, namely when a note in the search results takes a very long time
to render.

The leading reason for the performance issue is that draft-js was applying
a new decorator to its note on every change to the search field. With the
search field updating instantly that left no time for the decorators to redraw
(and they were very inefficient to make it worse).

In this patch we're delaying the re-decoration until the search field settles.
This doesn't eliminate the problem but it should bring it roughly on par with
the behavior from before the search updates. Further we have eliminated the
MultiDecorator dependency since that functionality is provided by draft-js
itself Scratch that - there's a slight API change that would require more code to change. Since there's no need to create a composite decorator when the search
query doesn't contain any text terms we can futher skip it and only decorate
with the checkbox decorator.

These changes should make searching tolerant to slow notes and should
additionally cut the time it takes to decorate notes approximately in half.

Changes

• delays highlighting search results inside of the open note when making search changes or when switching notes. the delay is currently set at 500ms and only affects notes whose contents are longer than 10,000 code units

Notes

• Long notes may still render slowly due to the cost of initializing draft-js. Further work to improve this probably needs to involve replacing draft-js

[belcherj]

Good to go. Tested and works well.