change LVL1Controller::rtPreActivateController and LVL1Controller::rtPreActivateController::rtPostDeactivateController to be protected

improve the HomogeneousMatrixCalculatorWidget (now it also shows the inverse and allows to multiply a vector with the matrix)

Conflicts:
	source/RobotAPI/gui-plugins/RobotUnitPlugin/RobotUnitPluginWidgetController.cpp

change RobotUnitPlugin to select the first lib containg the word controller of the currently selected package

apply astyle formatting

changed RobotUnit::getLVL1ControllerClassDescriptions to fail if the robot unit is not initialized after some time

# By Raphael
# Via Raphael
* 'RTRobotUnitV2' of https://gitlab.com/ArmarX/RobotAPI:
  change some status flags of LVL1Controller to be atomic change RobotUnit to deactivate publishing for every controller on exit (if publishing was active before) change the LVL1Controller publishing hooks to be protected
  change RobotUnit::publish to also skip RobotUnitState::Exiting and check for skipping again after the lock was acquired
  change RobotUnit to delete LVL1Controllers potentially beeing forgotten in the queue of controllers to be deleted
  changes the icon of the button to deactivate a controler to a pause button (RobotUnitPlugin)
  add the possibility to delete LVL1Controllers (deletion may be impossible for some controllers. e.g.: controllers used by the kinematic unit) extend the gui to be able to delete controllers extended the RobotUnitListener to carry this information (lvl1ControllerDeleted) extended LVL1ControllerDescription to carry this information add LVL1ControllerInterface isDeletable and deleteController

Conflicts:
	source/RobotAPI/gui-plugins/RobotUnitPlugin/RobotUnitPluginWidgetController.cpp

change RobotUnit to deactivate publishing for every controller on exit (if publishing was active before)
change the LVL1Controller publishing hooks to be protected

change RobotUnit::publish to also skip RobotUnitState::Exiting and check for skipping again after the lock was acquired

change RobotUnit to delete LVL1Controllers potentially beeing forgotten in the queue of controllers to be deleted

add the possibility to delete LVL1Controllers (deletion may be impossible for some controllers. e.g.: controllers used by the kinematic unit)
extend the gui to be able to delete controllers
extended the RobotUnitListener to carry this information (lvl1ControllerDeleted)
extended LVL1ControllerDescription to carry this information
add LVL1ControllerInterface isDeletable and deleteController

rename RobotUnitInterface switchControllerSetup to switchLVL1ControllerSetup (to keep the naming scheme)
rename RobotUnitInterface activateController to activateLVL1Controller (to keep the naming scheme)
rename RobotUnitInterface activateControllers to activateLVL1Controllers (to keep the naming scheme)
rename RobotUnitInterface deactivateController to deactivateLVL1Controller (to keep the naming scheme)
rename RobotUnitInterface deactivateControllers to deactivateLVL1Controllers (to keep the naming scheme)
rename RobotUnitInterface createController to createLVL1Controller (to keep the naming scheme)
rename RobotUnitInterface createControllerFromVariantConfig to createLVL1ControllerFromVariantConfig (to keep the naming scheme)

rename RobotUnitListener lvl1ControllerAdded to lvl1ControllerCreated (now the method createLVL1Controller triggers lvl1Controller created instead of lvl1ControllerAdded)

add the function checkSetOfControllersToActivate which allows deriving classes to check the set of controllers being requested (and throw an exception in case the set is not ok)
add a bit of doxygen

add factories for variant data classes from RobotAPI to be used by the variant widget

See merge request !25

Conflicts:
	source/RobotAPI/libraries/core/Trajectory.cpp

features:
	list ControlDevices + ControlTargets
	list SensorDevices + SensorValues
	list LVL1Controllers and invoke functions that have a WidgetDescription
	list ControllerClasses and create LVL1Controllers if the classes support it by providing a WidgetDescription used for configuration
	load libraries into the RobotUnit

major changes to version 1:
        LVL0Controllers for one unit (e.g. platforn, joint) are now grouped in a ControlDevice
        DataUnits are replaced by SensorDevices containing a SensorValue
        ControlTargets and SensorValues areautomatically swapped out to the non rt side
        there are default implementations for kinematic, platform, force torque and inertial measurement unit
        lvl1 controllers can provide a WidgetDescription used to configure and create them
        lvl1 controllers can provide WidgetDescriptions for methods they provide
        the robot unit now is initialized in multiple phases