Very nice!
A few remarks or suggestions:

1. For the GUI: Maybe add a line break after the checkbox, so that the controls for adding a new save actions are below the checkbox (and maybe add some indention). Write "field" in the textbox and delete it upon focus (similar to how the search box works). Decrease width of delete button. Besides that It is already prettier then the usual JabRef UI 😄
2. I think the SaveAction and CleanupFormatter classes can be merged with FieldFormatterCleanup (all of them essentially just store a field and a formatter). Is CleanupFormatter even used? Moreover, the SaveActions.applyActionForField method is covered by FieldFormatterCleanup.cleanup. Replacing SaveAction by FieldFormatterCleanup has also the advantage that the SaveActionsPanel can be used to add arbitrary formatters as cleanup operations in the cleanup dialog.

Again, the things I stated above are implemented and, hopefully, this can soon be merged.

Just a few remarks:

• Personally, I like the text "Add" and "Delete" better than the Icons that are displayed now, but whatever...
• Undoing save actions after save works via the menu Edit -> Undo. For some reason the key binding CTRL + Z does not trigger an action after save. I consider this a bug that should be fixed outside of this PR.

• Strange side effect: if I add save actions, the save sort order is added as well. I just enabled the save actions, and this was added:

+@Comment{jabref-meta: saveOrderConfig:original;;false;;false;;false;}
+
+@Comment{jabref-meta: saveActions:enabled;
+pages[PageNumbersFormatter]
+;}
+

• Removing all save actions and disabling it does not remove them from the file.

+@Comment{jabref-meta: saveOrderConfig:original;;false;;false;;false;}
+
+@Comment{jabref-meta: saveActions:disabled;;}
+

Even when they are enabled but have no configuration, they are stored.

+@Comment{jabref-meta: saveOrderConfig:original;;false;;false;;false;}
+
+@Comment{jabref-meta: saveActions:enabled;
+;}
+

I propose to only store them if they are really used. Otherwise, nothing should be stored in the bib file.

And the serialization format changes if save actions are enabled or disabled, as shown in the examples above.

And it's implemented.

I guess this PR will never end, will it? ;-)

Mhhh... maybe it is better to apply the save actions not in the DatabaseWriter but in another place (savesession?). Because of separation of concerns and so... What do you think?
(I would also remove the undoable prefix in the field changes name. The field changes are apriori just a list of changes and have no ability to be reverted. The revert functionality is added by the UndoableFieldChange class)

Could you also please add the TrimFormatter and RemoveBracesFormatter from #853. Thanks!

Once more, the above comments are implemented and this PR is ready for review. Discussion points:

• I added the default actions as recommend by @simonharrer
• @tobiasdiez Regarding the relocation of the application the save actions: I am not convinced why SaveSession would be a better place for applying the save actions. Right now SaveSession is more of a storage object for information regarding a save. If we integrate the application of save actions, SaveSession would need to know about BibEntry, which it currently doesn't. Moreover, the BibDatabaseWriter also resorts the entries, so why not apply the save actions there? It also requires the application of save actions before writing. All in all, I currently could not find a better place for applying save actions, but I am still open for suggestions.
• I took the liberty to implement a new feature: I you choose all as field name in the save actions, the selected formatter will be applied to all fields of all entries in the database. Say you want to always trim all fields, this sounded useful. However, the TrimFormatter in its current fashion does not work, since BibEntry.getField for some reason returns a trimmed version of the field content regardless of the content of the GUI. But that is a bug unrelated to this PR, which won't be fixed in this PR. As another example, lower casing all fields works just fine.

(Note: I will take care about the codacy stuff in a final step after we aggree on merging the current feature set, but not now when things might still change)

I'm in favor of merging this in! (Especially since I want to use the feature 😃 ).

@lenhard It was more a feeling that the application of save actions might have a better home somewhere else. But your are right, the DataBaseWriter is probably the right place for now.

About the icons: why not use the icons for adding and removing files in the Entry Editor -> General?

Otherwise this seems good to be merged.

Nice job 👍