Layered handling of node and (sub-)system errors

首先阅读 issue #43，以及关于 ModeManager、diagnostics 和 MROS Metacontroller 的讨论。文中没有指定源文件或测试，并且在实现可以被视为完成之前，还需要就诊断接口和预期行为达成一致。

from (#47 )

This is in the context of our exemplary case of the laser_driver error. We want to elaborate on the layered approach we discussed in the last MROS meeting. This is how I interpret our desired design (please comment if something is not correct or clear):

1. First the laser_driver code for handling errors tries to recover from the error in the ErrorProcessing transition state.

(from here it is a related but different issue)

2. If it does not succeed (I guess that means node does not transition to Active), the ModeManager tries to recover from the error using the feature/rules. For this, @jginesclavero is adding a rule in the SystemModes file of our system.
3. If there is no rule, or there is but after applying it the alternative MODE(s) of the laser_driver are not reached either, the ModeManager reports to the MROS Metacontroller that the corresponding (sub)system(s) MODE(s) are not reachable.
   (see issue for the continuation of the handling of errors at the higher layers)

continuation

Currently this will be implemented in a passive way, by offering that information (see https://github.com/micro-ROS/system_modes/issues/43)
But, since the current target MODE cannot be reached... we were thinking (in a discussion with TUD and URJC) if the ModeManager should report this actively system wide, for the operator or any supervisory system (e.g. MROS Metacontroller) to handle it.

Proposal: Since not being able to reach the target MODE is a deviation of expected and desired behaviour, we propose that the ModeManager uses diagnostics to report this. The MROS Metacontroller will subscribe such diagnostic messages.
(@fmrico @jginesclavero @marioney please comment if I missed something or did not convey it correctly)

What do you think @norro ?