Keyboard interaction

#777 fixes the most major issues for keyboard users, but a few issues remain. Most of these are more minor and/or would require more work to fix.

- [x] The dropdown menus from the top bar can be opened and used, but their tabindex is appended to the end of the page. So once you open the corpus dropdown, you have to tab through the _entire_ page to get to the list of corpora. My proposed fix would be to use the standard bulma dropdown menu instead of the primeng menu, that seems to do it. You would need to edit the CSS to keep the menu's signature look.
- [x] When tabbing through the filters: if you focus on the date filter it immediately opens the menu, which is fine. However, if you leave the menu by tabbing to the next control or pressing escape, the date filter is set to "active" even though you did nothing. (closed by #1139)
- [ ] The tab order of the pagination controls does not match left-to-right order, which is unexpected but not unusable.
- [x] Several buttons are `` elements when they should be ``, or [explicitly add keyboard interaction](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role). This applies to:
- [x] The download table data button for visualisations
- [x] The "show all fields" button in the fields dropdowns for searching and download
- [x] The descending/ascending toggle button for sorting results
- [x] The buttons at the footer of the document view (closed by #1169)
- [x] The search results / visualisions tabs (closed by #1168)
- [x] When opening a document, tabbing continues to cycle through the controls in the background. Interaction with the background should be disabled while viewing a document, and pressing tab should focus on the first control _within_ the document view. (closed by #1169 )
- [ ] Charts do not have keyboard interaction. Mouse interactions are: tooltips showing the values of datapoints, zooming in the barcharts, dragging nodes in the nearest neighbours network. None of these show data that cannot be accessed through the table view or filtering, but those are more cumbersome routes.
- [x] The range filter triggers an update with the `onSlideEnd` event of the slider, which is only triggered when using a mouse to drag the slider. It is not triggered when using the keyboard (or clicking on the slider, for that matter)
- [x] In the search history, each query links to the relevant search request, but these links are not accessible by keyboard.
- [x] ~In the corpus header, the corpus information button has no indication that it receives focus.~ (obsolete since #1143)
- [ ] For document scans, keyboard controls allow zooming in/out, but not panning. Also, the maximum zoom level for the scroll wheel is much higher than for the button. For a corpus like the times, keyboard zooming does not actually result in a readable scale.