Fix #3292: annotations are now automatically refreshed

[tobiasdiez]

This PR aims to fix #3292 by removing the refresh button completely and monitoring the pdf files automatically for changes. In the progress of the implementation a few refactorings were made:

• Extract the file monitoring functionality from FileUpdateMonitor to a new class and convert the timestamp-based method to the new nio watcher interface.
• Extract the conflict handling code by external bib file changes from the base panel to a new class DatabaseChangeMonitor, where also some of the old code from FileUpdateMonitor now finds a new home. This class is still a bit ugly but in my opinion better than before. I hope that the conflict handling still works as expected. I tested it but might have missed some special cases/configurations.

---

• Change in CHANGELOG.md described
• Tests created for changes
• Screenshots added (for bigger UI changes)
• Manually tested changed features in running JabRef
• Check documentation status (Issue created for outdated help page at help.jabref.org?)
• If you changed the localization: Did you run gradle localizationUpdate?

[lenhard]

The changes are a bit hard to review, but I have tested it locally and the annotations are refreshed as desired.

I have another point, though, one that might entail some work. Since you are already touching this code, do you see a change of refactoring the complete collab package, so that it fits better to our architecture? If we just take the current dependencies in the package, then the whole thing would basically go into gui. This already would be an improvement, because the source code packages in root would already look a little more like where we want to go.

But to be honest, I do not get why file monitoring functionality should belong into the gui part. At least part of that should be extractable into a non-GUI part and should be movable into logic. If I look at ChangeScanner, then basically everything from line 164 downwards is GUI-independent code. I also don't see why Change and its subclasses should be so heavily tied to UI code. As far as I can see this is only, because the code is tied so strongly to the undo framework. Couldn't we extract that part and move the Change classes to a deeper layer?

[tobiasdiez]

Ok, I'll merge this now and will have a look at the collab package later. I second your concerns @lenhard, much of the code their should actually reside in logic. This would also help @Siedlerchr in his endeavor towards sharelatex integration.