Fix broken keyboard navigation in the help browser.
This resolves a long-standing bug (the relevant code is 4-5 years old). While it is just one little missing check in the keyboard event handler, which is surely just an oversight, this has the dire consequence of breaking navigation with the Tab key. - The root cause for this issue is in the document.body event listener callback, where we always reset the focus to the search text input if there's *any* keyboard input (other than a LF or CR on the file browser and bookmark buttons) while the focus is on something else (such as an item in the toc or in the search results). The intention there surely was to enable the user to just start typing *anywhere* in the dialog, which is convenient, but has the unwanted side-effect of breaking Tab navigation (as well as the cursor keys). - The fix is simply to *not* reset the focus if the key event is the Tab key. Besides Tab, we also treat the modifier and cursor keys in the same fashion, so that these will be handled on the spot rather than being forwarded to the search text input. By these means, you can still start typing your search terms from anywhere in the dialog, but navigation with Tab and Shift+Tab and the cursor keys now also work as expected. - Also, why is the div holding the toc items created again and again for each item in display_toc()? I moved the corresponding statement, div = document.createElement("div"), right before the toc.forEach() loop now, which I think is where it really belongs.