Optimize title search so that cancelled binary search Promises return at the earliest possible opportunity

[Jaifroid]

This relates to the optimization of #617. Although searches are successfully cancelled when a user starts a new search or exits the search UI, and extraneous results from a cancelled search do not display in the UI, a certain amount of binary search processing still continues from Promises which had been set up very early on in the search process. It should be possible to return a null result, or use throw, from those Promises to prevent unnecessary CPU utilization. This has to be done without simply dereferencing parameters and causing potential memory leaks. It is similar to #426, where a fair amount of processing for a previous article continues after a user has navigated away to another article. Similar techniques could be used to solve both situations.

#617 (comment) is particularly relevant to understand the issue here.

[Jaifroid]

So I don't forget, here is a quick summary of what needs to be done following on from #617:

• Move globalstate object from init.js to app.js; possibly rename appstate;
• Pass the appstate.search object to zimArchive.js;
• When a search is cancelled, set the appstate.search.status property to 'cancelled';
• When a new search is undertaken, also set appstate.search.status to 'cancelled': this will be reflected in the search object passed to zimArchive.js because they both still point to the same underlying object;
• Instantiate a new search object, and set appstate.search to this new object; the one passed to zimArchive.js will still point to the old object according to Javascript Pointer Reference craziness;
• Insert an early cancellation at the very start of the binary search loop: if a search status is cancelled, return 0 instead of -1 or +1 -- this causes the loop to exit early;
• Once all Promises have returned, the old search object is no longer referenced, and should be garbage collected automatically in due course.

[Jaifroid]

If this works, extend the model to #426, which is a very similar case: we should be able to use the same appstate object to pass an appstate.article object, which would have a property appstate.article.status. In Service Worker mode, if we are allowed to emit a signal from the message channel that the user has clicked on a new article link, then this solution should be viable.