Target column names are made with Attribute definitions

[DavidLeoni]

There are issues with target columns, that is, columns mapped to a target attribute. This is also related to caching #149

Since

• the names of target columns are given by the name of the target attribute definition in the language of the UI
• attr def names alone are not sufficient to indicate that target attribute is nested (i.e. instead of storing and displaying just Street we should store an attr def path and display Address->Street)
• columns in Refine must have a unique name

It follows instability occurs when:

a) etypes are changed externally renaming attr defs or deleting them, and cache is then refreshed - Note renaming can happen also by adding translations to synsets representing the attr def. Further breakages can be caused by the user replaying a script which use old attr def name
b) UI language is changed
c) by great misfortune an attribute name can't be displayed in the UI language because the correspondent translation is missing, so ODR displays it in another language and that label is equal to some other attribute def in a target column.

SOLUTION FOR COLUMN NAMES:

Instead of string names we should store attr def URL paths which should be more stable. Maybe we could squash them in stringified form to suit Refine string label for columns. Then to the user we would display nicely formatted attr def names like Address->Street

SOLUTION FOR SCRIPTING:

While for convenience purposes we should allow a user to type in a GREL script the currently displayed column name, once the script is submitted to Refine we should resolve the name to find the attr def url path and actually store such path (maybe along with the name typed by the user). This would provide resilience against future attr def renamings.