Record search history

[MaryJml]

Fixes #7906

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[calixtus]

Could you check if there can some code be shared as a new list type with the FileHistory class? I remember that I worked some time ago with a similar mechanic to limit the max number of entries in the list.

[Siedlerchr]

Tested it locally works fine!

[HoussemNasri]

I played around with this feature locally and I noticed that sometimes if I type the search query slowly enough, some of the prefixes of the query are recorded along the actual query. Not having a search button that starts the search task made it hard to select the correct time to perform the search. Currently, JabRef waits for the search box to be idle for 400ms and then performs the query. This is a good time to show the search results because JabRef will feel more interactive, but not so good for adding the query to the history because the user may be unhappy with the results and continue to modify the query, or he may simply be a slow typist like myself :^)

I gave this some thought and these are a few suggestions:

1. Record query when the search box loses focus
Thinking about the search workflow, it would look something like this:

1. User wants to search for something
2. User derives a query that matches the pattern he/she has in mind
3. User types the query and modifies it until it shows the intended results
4. User selects the entry he/she is searching for

Looking at the workflow above, it seems best to record the search query after step 4: User selects the entry he/she is searching for a.k.a the search box loses focus.

2. Merge recorded search queries with a certain similarity score that were recorded in a close timestamp
If I want to search for 'hello', in the worst case the search history would record all of the prefixes: 'h', 'he', 'hel', 'hell' and 'hello'. We can develop an algorithm that can understand that all of these queries refer to the same query which is 'hello'. We already have a utility class to calculate the similarity between two strings: StringSimilarity, so that's one piece of the problem solved.

After a query is recorded the algorithm would loop through the list of the recorded queries and decides if the new query could be an update to an older query. It goes like this:

1. The algorithm notices that 'h' and 'he' were recorded 1s apart and they are similar enough so it would remove 'h' and insert 'he'
2. The algorithm notices that 'he' and 'hel' were recorded 1.5s apart and they are similar enough so it would remove 'he' and insert 'hel'
3. etc...

[Siedlerchr]

I would suggest we merge this current as is, and I will move @HoussemNasri comment to a follow up issue