Separate Options from data storage

[uliska]

Also related to #2

Currently some packages (and many projects, at least my own) use oll-core's option alist to store all kinds of data. This is probably not a good idea because it makes the option tree pretty complex, and maybe it's even unefficient.

It is unclear how this should be approached, but here are some thoughts:

• there should be an interface for createing new data storage objects, beyond directly using the Tree implementation.
• maybe in addition to the option tree there should be one second oll-data alist where arbitrary data trees can be added as top-level entries.
• it should be possible to use different implementations for these data tree objects, but there must be a common API to manipulate them, agnostic of the tree implementation

[uliska]

The chamged alist-access module that doesn't store its alists in the public namespace anymore is a first step.

There might be an optional argument to the options commands specifying the tree to use.

OTOH it might be a better approach to use property sets for storing data in the first place