GUI: SelectionProperty: preparation to replace Descriptor

Current selection mechanism for setting up sample and instrument is based on so called "catalogs".

Catalog is a class that contains list of target classes, between which we choose, and supporting information: labels, icon paths, enumeration lists.

SelectionProperty may operate on such catalog, it owns the instance of currently selected class, provides serialization interface, common label and tooltip.

This hierarchy looks reasonable and the goal is to simplify it, diminishing the generality, and merging SelectionDescriptors to SelectionProperty

SelectionDescriptors, like other previously existed descriptors, are generic interfaces that may represent corresponding property or can be build ad hoc to represent other parameters in the same way. But SelectionProperties may represent themselves without sharing functionality between two similar classes. If SelectionDescriptor is constructed for non-SelectionProperty object, that means that we need SelectionProperty here. So that descriptors should be eliminated.

Steps of SelectionProperty/Descriptor refactoring:

1. make SelectionProperty less generic, make catalogs usage mandatory, not optional
2. reduce usage of ad hoc SelectionDescriptors, e.g. descriptors that are not derived from SelectionProperty
3. move Descriptor functionality to Property
4. use Property instead of Descriptor
5. remove Descriptor from code
6. refactor serialization of Property

This MR is related to points 1 and 6.