TextView should use label provider of property descriptor instead item provider

[Matthias Schoettle]

Currently, when requesting the textual representation of a model object, the TextView does the following:

if (showFullLabel || data == null) {
    object = data;
} else if (data.eClass().getEAllStructuralFeatures().contains(feature)) {
    object = data.eGet(feature);
}

For the object, the text is retrieved via EMFEditUtil.getText(...). This uses the item provider of the object. However, in the case the text for a certain feature of a model element (else branch) is wanted, this might lead to the wrong text. I.e., the text depends on the structural feature and is not always the same for a certain model element.

For example, for the new way of reusing association (selecting features on the association end), the textual representation of the feature should be the selected features. However, the referenced object is a COREModelReuse and its textual representation should not change. Similarly, the name of an aspect could be composed of ConcernName.AspectName realizes FeatureName in certain cases, but in others it is just the name of the aspect.

So instead of getting the value of the feature, EMFEditUtil.getPropertyText(...) should be used to retrieve the textual representation in that case.

[Matthias Schoettle]

References #286: Adds the use of getting the property text when a feature is displayed and the full label is not required. In case no property descriptor is there, getText is called instead as a fall back.

This now allows a different textual representation on a per-feature basis, which means that now the textual representation will match the one shown in the selector when selecting a different element.

→ <<cset 80626a9402de>>

[Matthias Schoettle]

Right now, the type reference of an operation's return type or a parameter's type displays the aspect name as a prefix, but this is deemed helpful, because it visualizes to the user that the type is from a different aspect.