Cache search objects in localStorage for faster search loading

[IanButterworth]

I'm hoping to speed up the displaying of search results after a page reload. It's nice and fast when updating the search box, but the building of the search dictionaries is really slow, especially on Base docs.

I see a few paths to do this:

1. Use a server-side search phrase -> results service - Can't be hosted by github pages etc. Won't work offline
2. Rework the docs pages to be within a long-lasting page and use frames to serve content so that the search dictionaries can be retained - Seems like a good idea but a lot of work. Will still be slow first load but perhaps that could happen async on the landing page?
3. Generate the dictionaries during mkdocs and deserialize them - Likely to be fast, but given users can provide custom search.js files (~~as Base does~~), it would likely be hard to make this work universally?
4. Store the index and store in browser local storage, which is per-origin, so that following page loads can use the cached versions

This PR is a demo of the last option.

Unfortunately, it's slower on first load and only slightly faster on following loads because of the need for compression due to the storage limit (on chrome at least) being 5MB, which the index of Base docs exceeds.

Perhaps the string size could be queried to see if compression is needed, but you'd need to know whether it was compressed at load time, so there would need to be an additional flag stored.

Anyway, I'm not sure this is a good idea, but I thought I'd share given it "works"

@mortenpi I recall we talked about some of this before

[IanButterworth]

Btw, one gripe I have is that I often instinctively press return after entering text in the search box, which, if you're on the search page already makes you needlessly hit the slow search load, given 1) the search results are likely already shown due to the text box update 2) the reload makes you hit the regeneration of the search dicts

Perhaps the return-key form entry could be disabled on the search page itself?

[mortenpi]

I haven't looked at this PR in detail yet, but if we get some caching, that would be awesome.

Perhaps the return-key form entry could be disabled on the search page itself?

Yes, I do that as well sometimes, so I think this would make a lot of sense. But separate PR might be good for this, as that's a no-brainer to merge.