- Change return type of getValue() to T
 - This allows for more type safe implementation of the underlying calculations
 - The former abstract base class DerivedAnnotationBase used Object as a return type for getValue() to due an EMF code generation bug for generics if the base class is located in a different .ecore file than the concrete class. For interfaces, this bug is not triggered.
  
refs 1841

Introduce "derived" annotation, i.e. based on calculations instead of explicit annotations / model contents can be implemented

- DerivedAnnotationBase meta-model element, with getValue() EOperation, and a extensive documentation.
- Corresponding DerivedAnnotationValueProviderBase, implementing a read-only, text-view of the calculation result
- To implement the above, move handling of annotation EClass & factory to ValueProviderBase

refs 1841

- Fix NPE in case a filter actually strikes

 - renamings of model elements (e.g., in the properties view)
 - addition of new instances of multi-instance annotations

-> Use originator of the notification, and not the new value to trigger the update
refs 1841

refs 1841

- Move column label provider displaying the model element names in the first column to a dedicated class ElementNameLabelProvider
- Introduce IAnnotationViewPart

- Ensure and document that all output of TextEditingSupport.getValue() is converted to a non-null String. This is required because this value will be consumed in TextCellEditor.doSetValue() which expects such input

- Apply <underlying EMF Factory>.createFromString() to all String input in order to ensure conversion for input received e.g. from TextCellEditors on all code paths

refs 1841

- Install {@link Adapter} to watch for the addition or removal of model elements to/from elements visible in this {@link AnnotationViewPartBase} (to trigger according updates).
- Ensure that all annotations for all offspring of the currently selected are shown in the view
- AnnotationViewPartBase no longer maintains a protected attribute with the list of current annotation entries, but triggers the abstract update(Collection<AnnotationEntry>) method at the right occasions (to be implemented by concrete views).
- Possible improvement in GenericAnnotationView: efficient implementation of update(Collection<AnnotationEntry>) (instead of complete redraw).
refs 1841

- Extend IAnnotationValueProvider with getter/setter methods to access individual instances of a multi-instance IAnnotatedSpecification

- The storage of the instances is based on an EMap<String, V> in the corresponding IAnnotatedSpecification.

- See MultiInstanceAnnotationValueProviderBase for documentation how to create the corresponding meta-model for the annotation types, and of course use it as a basis for specific multi-instance value providers.

- Merge SingleAttributeValueProviderBase and SingleEDataValueProviderBase to SingleEStructuralFeatureValueProviderBase, and generalize it to work on EStructuralFeatures. This is required to support both EAttributes and "contained" EReferences as annotation storage in the meta-model.

- With the above change, cleanup and extend the instantiation of annotation attributes / contained references to EClasses.

- Extend the GenericAnnotationView to enable instantiation of multi-instance annoations.
refs 1841

- IAnnotationValueProvider
  - allowsMultipleValues() -> allowsMultipleAnnotationInstances()
  - createEditingSupport()
     - Remove unused parameter
     - Method is unconditionally used to construct the editing support. Defaults
       are set in base classes implementing IAnnotationValueProvider.
  - remove getFixedValues(): SingleEnumAttributeValueProviderBase() creates the required ComboBoxEditingSupport
  
- IAnnotationValueProvider base classes:
  - ValueProviderBase: Empty implementation of interface
  - SingleAttributeValueProviderBase: IAnnotationValueProvider manages a single attribute of a given specification class. Probably nearly all static annotations will be based on this.
  - SingleEDataTypeAttributeValueProvider: primitive data types (e.g., int, double), and potentially many other data types managed by EMF
  - SingleEnumAttributeValueProvider: Provides ComboBoxEditingSupport based on enum declaration in Ecore meta-model.

- Further fixes:
  - Make combo box in ComboBoxEditionSupport non-editable
  - Prevent NPE in TextEditingSupport.getValue()
  
- Use new base classes in test annotation classes
refs 1841

- Provide generic abstract base classes:
  - ValueProviderBase -> for generic annotated specifications
  - SinglePrimitiveAttributeValueProviderBase, for annotated specifications whose storage is implemented by a single primitive attribute (Double, Integer, String, etc.)

- Introduce sub packages for annotation framework (see org.fortiss.tooling.base.ui.annotation -> package.html for documentation)
- Standardize class names

 - add setAnnotationValue(String value, T specification) in addition to setAnnotationValue(V value, T specification) variant
 - This enables to use the String-based AnnotationEditingSupportStandard for non-String annotations.
 - Concrete AnnotationValueProviders must implement this method and convert the String representation of the input to the storage format provided by the respective annotation class (e.g., for Double, just by using the Double(String) constructor)
 - The current implementation  has been tested with String, Double, enum and multiple value String annotations

- TODO:
  - Cleanup of IAnnotationValueProvider
  - Base class hierarchy for common concrete annotation value providers
  - multiple value annotation support in GenericAnnotationView

refs 2093

refs 2093

refs 2093

refs 2093

refs 2093

refs 2093

refs 2093

fix of failures: was again due to the EMF annoying thing of forcing non-duplicates in function arguments
refs 2077

refs 2093

refs 2093

refs 2049

refs 2066

refs 2093

refs 2093

refs 2093

refs 2093

refs 2093

refs 2093

refs 2093

refs 2093

refs 2093

refs 2093