Preferences cleanup

[calixtus]

Some refactorings and rewordings working towards next release and abstraction of a preferences layer to prepare modularization to clean up after some messy PRs.

• Rewords directories
• Merges ImportSettingsTab and CustomizationTab to the new Import and Export (for future) Tab
  
• Moves allowIntegerInEdition option to the EntryEditorTab

.

• 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 documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.

[koppor]

So far, I see ImportformatPreferences is replaced by the PreferenceService. Since that service is our current way to go, I like the progress so far. Later, this service will be injected by a dependency injection framework such as Google Guice.

[koppor]

Hint on reviewing: Do not look at "Changed files", look at the commits one by one ^^.

[tobiasdiez]

The change from ImportFormatPreferences to PreferenceService now introduces a dependency of the logic package on the preference package. The goal was actually to have the logic completely independent from the preferences (i.e. on the store/load operations), and only pass small preference data classes (such as the ImportFormatPreferences) to the logic package. See for example the todo here:

jabref/src/test/java/org/jabref/architecture/MainArchitectureTests.java

Line 105 in 1dc3203

.whereLayer("Preferences").mayOnlyBeAccessedByLayers("Gui", "Logic", "Migrations", "Styletester", "Cli") // TODO: Remove logic here

What is the idea behind this change?

[calixtus]

DevCall discussion (2021-07-05):

• https://devdocs.jabref.org/getting-into-the-code/high-level-documentation
• Discussion on granularity. Should the PreferenceService be a "huge" DTO or should we use the stripped down "small" preference objects (such as org.jabref.logic.importer.ImportFormatPreferences)
• Long run: integrate org.jabref.preferences into org.jabref.logic
• Discussion on keyword separator --> maybe introduce FetcherPreferences object -- same setting; stored once, but preference service puts it into FetcherPreferences, ImportFormatPreferences, CLS...-Preferences. We accept that alias issues could occur.
• Preference classes should follow the use case
• For each logic package: one preference class (collecting the features of the package) - even if not all citizens of the package use all preference, but that helps to reduce the number of preference objects passed --> this avoids a "pseudo-global" "variable"
• Discussion on using JavaFX observables at the preferences (to avoid JabRef restart on preferences changes)

[Siedlerchr]

I would keep the CustomizatonTab as a separate, because it not necessarily represents import/export things (at the momet it does, but in future it might not)

[calixtus]

In that case we can add it again and it should be very easy to do so. But as long we dont have something for that customization tab I don't think we should keep it and group the prefs as we need them now.