Notifications Preferences editing UX is not consistent with XWiki's editing UX

XWiki's UX on editing preferences is currently done by considering 2 modes: view and edit. When the preferences are to be edited, the page is opened in edit mode, locked, the preferences are selected, the page is saved and finally unlocked.

Alternatively, Wiki Preferences use the admin mode, instead of edit, but the behavior is the same.

Notifications Preferences do not follow this pattern and adopt a "save on change" interaction (instead of "save when done") and there is no distinction between view and edit mode, which also makes page locking impossible.

IMO, it's not a good idea to be inconsistent and, if we want to switch to the "save on change" and "edit mode by default", we should at least discuss it, in order to avoid an entire class of problems, like concurrent editing (e.g. an admin edits in object mode and a user saves in the "edit mode by default"; what happens? Does the user's save fail? Does it go through and is then overridden by the admin's final save? etc.)

This is the current Notifications Preferences, in view mode (displayed like it's in edit mode, with no "save" buttons, but with "save on change"), on the user's profile page: