Improve chronological navigation

[subhramit]

This issue has multiple areas of exploration, not recommended for newcomers but highly recommended for people who love debugging.

Chronological navigation per-library was re-introduced in #13863

Phase 1 - Experiments

The following cases were not taken into consideration during development:

1. What happens if multiple entries are selected (using Ctrl + click), and then another entry/group of entries are selected? - Investigate. See if you are able to co-relate the behavior with the code.
2. What happens if an entry that is present in the navigation history is deleted (removed from the library), and then one tries to navigate to it chronologically? - Investigate.
3. Remove/prevent "Ghost" navigation history when using importers #13878 (most probably an issue with listeners)

Phase 2 - Development

Plan & hints

• In case of 1, we should support selecting a group of entries as one history "entity" that we can chronologically traverse back and forth to. Motivation behind this idea can be found in Chronological navigation in libraries #13863 (comment) (cc: @InAnYan). One obvious idea may be using a "list of list of history entries" per library instead of a "list of history entries". Challenge would be to demarcate the previous group of entries from the next group and adding it to the next list inside the parent list. A hint can be to find if existing methods/listeners (or new ones, if needed) can be used to trace the "de-selection of previous selected entries due to selection of a new one" - and this "new one" can be an entry belonging inside or outside the previously selected group. In simpler words (from a user's perspective), imagine ctrl+clicking a couple of entries, then "just" clicking on any entry - so that the previous ones are de-selected.
• For part 1, another aspect to take care of would be "which entry should be displayed in the entry editor if a group of entries is navigated to in history?" - A simple answer to this would be the standard expected behavior - when normally selecting a group (using ctrl+ clicks), the last entry selected is the one open in the entry editor. So during chronological navigation too, the last selected entry of the group (in order of addition in the sub-list mentioned above) before the next group (list) is introduced should be the correct state to restore for "undo"/"redo" to open in the entry editor. Lets call this an "anchor" entry. This anchor entry for each group (sub-list) should be separately marked/captured so that at the end of the navigation action, it can be selected in the entry editor.
• In case of 2, if any unexpected behavior occurs, report it under this issue and improve the implementation to handle it gracefully - removed entries should also be removed from the navigation history. Navigation should work as intended - as if the removed entries never existed during the creation of the history list. If the behavior is already fine, report that too. (This may also intertwined with point 1)
• In case of 3, details of what to do are already given in the linked issue.

Note

Since this is a user-facing change, a screen recording of the functionality working in JabRef UI is mandatory to be provided in the description of the PR to mark completion.