Centralize in KB all info needed by nodes of the metacontrol MAPE-K loop

Currently, there are some ad-hoc code to provide each of the nodes in the metacontrol MAPE-K loop the information about configuration. We need to have a general solution to sync this information, which includes:

existing configurations (aka FDs in tomasys, aka rossystem files in ROS model), that is the KB
the current objective and associated NFR (obj+NFRs), and
the current configuration deployed - see https://github.com/rosin-project/mros1_reasoner/issues/28

Let's analyze this per metacontrol node in the MAPE-K loop (checkboxes indicate the design stated next to it has been implemented):

Monitor: `rosgraph_monitor`

`ROSGraph monitor`

It monitors that the configuration of nodes/components is the desired_configuration

use a component model: currently it uses the initial rossystem model at deployment and the current rossystem generated by ros_graph_parser
[ ] TODO (not for paper): update dynamically at runtime the desired_rossystem with the new configuration deployed by metacontrol

`Objectives observers`

They detect the status of the running objectives (are they in error because the task management reports so?)

[ ] TODO: required for many scenarios (move_base cannot plan route in navigation, tag not detected in Cheops)
We could monitor action goal feedback, if we associate objective <-> ROS action goal
This could be "merged" with QA Observers
QA Observers:
- [ ] TODO (not for paper): They need to know for which objective they are reporting QA values, either by knowing the objective or by knowing the configuration that is achieving those values. Currently: only one objective and 1 configuration assumed, mros1_reasoner does the association QAvalue-Objective
- Deployment time: they are automatically generated using RosModel tooling (see @ipa-nhg please add your pull request on autom creating observer models) and a template.
[ ] TODO (not for paper): currently for MVP the application launchfile including the observers is a manual one by @marioney rosgraph_nodes.launch.xml in https://github.com/rosin-project/metacontrol_sim/blob/1a8c38645bcd141611cd628520226a7a80134c78/launch/MVP_metacontrol_world.launch#L61
[ ] TODO (not for paper): generalize/automate the addition of the QA observation model to the observer (ilnk to Nadia's issue on this)
- Dynamically at runtime:
for a given obj+NFRs they do not need to change.
[ ] TODO (not for paper): for dynamic objestives+NFRs they need to adapt, e.g. metacontrol could deploy dynamically new

NOTE: observers need to be activated (see code below). This needs to be "automated". mros1_reasoner could do that, contributing to address the deployment and the runtime TODOs https://github.com/rosin-project/metacontrol_sim/blob/1a8c38645bcd141611cd628520226a7a80134c78/launch/MVP_metacontrol_world.launch#L75-L77

IMPLEMENTATION NODE for Monitoring: Currently the monitoring interface M-A is via ROS diagnostics messages This is causing some problems and does not provide good semantics

[ ] TODO (not paper, but IMP): implement a specific metacontrol monitoring interface in a new ROS message type

Analyse, Plan and KB - `mros1_reasoner`

Deployment time:
- [x] load the application ontology file
- initialize obj+NFRs and current configuration (see https://github.com/rosin-project/mros1_reasoner/issues/28)
- currently: initialized in reasoning code: https://github.com/rosin-project/mros1_reasoner/blob/5263ad6da4a7507754caf6dbf0068e774c223b65/mros1_reasoner/scripts/init_models.py#L46
- [ ] TODO: separate it from the reasoning code, i.e. separate application-specific. Options:
- Use params see https://github.com/rosin-project/mros1_reasoner/issues/28
- init them from RosModel in the KB
- [x] model them in the RosModel: see @ipa-nhg system.rossystem params
- [x] load them in the KB

Execute - `rosgraph_manipulator.py`

https://github.com/rosin-project/metacontrol_sim/blob/1a8c38645bcd141611cd628520226a7a80134c78/scripts/rosgraph_manipulator.py#L100-L125

It requires the Knowledge of configurations to execute the adaptations:
- For the moment Metacontrol implementation considers configurations/FDs as atomic adaptation elements, so it only needs to know how to start and kill configurations.
- Currently kill&launch model with launchfiles
  - [x] launchfiles used are autom generated from models
  - rosgraph_manipulator.py uses a YAML file with the configurations name
  - [ ] TODO: autom sync configurations with KB, so as not to have that info twice. Options:
    - automatically generate the YAML file
    - use the KB (ontology). Options
    - move Execute to mros1_reasoner to use the KB
    - rosgraph_manipulator.py also accesses the ontology.
      - using Owlready2 requires to move this to metacontrol ws with python3. We could simply load the same owl file. Problem: can be out of sync if we use dyn info at runtime
      - using distributed KB in ROS, e.g. ARMOR
- [ ] TODO: consider more complex reconfigurations models than kill&launch: some nodes need to be put in a safe state before killing, some states could need to be saved, etc

rosin-project / metacontrol_sim