Refactor concept features

[reckart]

The current approach of listing all possible concepts in the feature type list in the feature editor is not scalable and not flexible enough. Instead, we need a generic concept of a KB feature and separately from that one or more ways to control the scope of the feature, i.e. which values it can assume.

• Instead polluting the feature types dropdown with concepts, show only a generic "Concept" type and choose the specific scope later
• Allow choosing a specific KB or any KB
• Allow creation of concept features which can accept "any" concept

[rcffc]

@reckart What is meant with trait and scope in the context of ConceptFeatureTraits?

[reckart]

"traits" are the configuration settings specific to a particular annotation type. I.e. all settings which are not directly part of the AnnotationType entity.

The "scope" and the "repositoryId" of the concept feature are such traits. The "repositoryId" identifies a particular KB to use (can be null to use any). The "scope" determines the concept whose instances we want to link with the feature.

I imagine more traits to come, e.g. one that configures whether we only want to link instances of the concept identified by the "scope" or if we also want to be able to link child concepts (and possibly again their instances).