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.