User preferences in CMS

The way user preferences for the CMS are currently handled is wrong:

Currently subclasses of AbstractListingPlugin (the Search, Documents and Tasks ListPlugins)
are the only Plugins with user preferences (pageSize and viewSize).
They are themselves responsible for reading and storing their preferences. In order to
do this they must have knowledge of where these preferences are stored (in Node this and that)

This should be the other way around: the frontend engine loads and 'injects' the Plugin with user preferences (if any)

We need a flexible mechanism for storing preferences. The actual location of the data should managed by the frontend engine,
whereas the content is up to the Plugin. Since user preferences are completely controlled by Plugins themselves,
the appropriate interface is JCR.

Therefore we need to provide a Node as the interface for storing and retrieving user preferences for a Plugin
instance in an application. The path and ancestors of the Node should be irrelevant to the Plugin.

— Proposal for implementation —

1> User preferences are stored under /hippo:configuration/hippo:users/<username>/<application>/<path-to-plugin>/hippo:preferences
2> Anything under that node is Plugin-specific and the only one who can interpret it is the Plugin itself.
3> When loading a Plugin the frontend engine injects that node in the Plugin
4> The Plugin reads it's configuration from it and is free to add anything it needs.