Implement linkset Data

[Yichard]

This replaces issue #140 , as a better solution, and implementable more easily.

In a nutshell, the linkset data set (new Second Life feature) is a 64k space to store name:data pairs in an object, to be used by scripts. There are no restriction on lenght and number of these, but all values are stored as texts. It is attached to an object, not a prim.
SL implemented a set of functions to write, read, etc. the data. One is here: https://wiki.secondlife.com/wiki/LlLinksetDataRead
There also is an event raised when a pair is modified, but we are not forced to use it.

The idea of #140 was to pass data between scripts, without using an event (without disrupting the flow of the calculus). The new solution allows for much more, like:
-store data from a config notecard, so that it is accessible for all the scripts
-store data in a way it survives a script reset, for instance in a roleplay HUD

In more the argument of the difficulty to add data fields to prims is lowered, since only the objects are altered.

Added: workaround is to store values as properties of a prim. For instance if we use the colors of a face, we can store 8 vectors (tested: works even on faces which do not exist) We can store dozen UUIDS as face textures, shiny map, etc. There are some caveats, though, stored values are usually clipped to what makes sense for a prim.

[Yichard]

I realize that, as the system is implemented in SL, if we lose track of a name:value pair, we cannot erase it. This can quickly happen in the deverloment phase, or if we store data line name of persons. So that there must be a way to edit the linkset data
-manually, as with a notecard
-with a function giving the list, or able to loop all along the list.

[mdickson]

That's what llLinksetDataListKeys is for:
https://wiki.secondlife.com/wiki/LlLinksetDataListKeys

[Yichard]

I was wondering how it is implemented in SL, and if we may have advantage in implementing it differently. There are several solutions:
☻A notecard. Advantages: the file format already exists, and it may be edited manually. Inconvenience: it is slow, especially if we have many value-data pairs.
☻A database, MySQL style. Advantage: the fastest.
☻A JSON text. Not as fast as MySQL, but this opens up the possibility of reading directly with a script. Especially we may have nesting levels. This one sounds nice, because nested values search must faster, because it is not needed to look through all the data.

That llLinksetDataListKeys uses numerical indexes suggests that the value:pairs are numbered. The simplest explanation is that they are numbered as they are created. Problem, if one pair is suppressed, the index of all the subsequent pairs is modified. So that this is not a reliable way to manage them.

A wise scripter may use the multiple features of https://wiki.secondlife.com/wiki/LlLinksetDataFindKeys to organise his values, for instance with hierarchical names:
village;house;room;furniture:position
(A semicolon is used there, because the dot is a wildcard for the function)
This one sounds nice, but a JSON-style nesting of values would be much faster, because the search do not have to look through all the data.