Modulo Version 6

[domire8]

For reasons very well described here, our current implementation of the modulo base classes (component, lifecycle component, controller) has quite a poor ABI stability. That means that each time we want to add new feature to those classes, it is very hard - or impossible - to do so without breaking the ABI. The longer we stick to one major version, the more our hands become tied in what we can still add.

That said, for modulo v6 we want to work towards libraries with higher ABI stability, using a set of techniques mentioned above. Most likely, we will implement some sort of PIMPL structure.

The current breaking branch already contains the following changes:

• feat(controllers)!: remove robot description parameter #186
• Add TF listener in BaseControllerInterface #169, Add TF broadcaster in BaseControllerInterface #170, test(controllers): add TF listener and broadcaster tests #172
• Input validity period should be parameter of base interface #207 (to be reviewed again)
• Update modulo translators for new trajectory messages #194 (to be reviewed again, depends on control libraries X)

@eeberhard @SprGrf @yrh012

In addition to this pure (breaking) refactor, we can implement any of the following for v6

[eeberhard]

It's tangential to the core issue but it might be worth revisiting the on_execute_callback and raise_error methods of unmanaged components with their associated is_finished and in_error_state predicates, to understand if and how we have actually used these interfaces or if we should remove them in favor of the standard interfaces provided by lifecycle components.