Robotics Service Bus

From my point of view, the specification of preferred converters may be conceptually at the wrong level (currently at the level of transports).

Considering Listeners, they should receive the same data type, irrespective of the used transport. If there are several converters for a specific wire-schema, a preference needs to be given at the level of the Participant.
Considering Informers, there might be different wire-schemas to be used for different connectors. Hence, here the configuration at the transport level is sensible.

Hence, there is a need to handle in and out connectors differently!

Also, there should be an application-wide (default) converter preference, which should be used as args to rsb::converter::Repository::getConvertersForDeserialization and getConvertersForSerialization instead of the undecided default. The mentioned methods are used all over the framework and will fail if ambiguous converters are registered.

This application-wide default should be initialized from the rsc config system before the plugin system can register converters. This will allow meta converters (that use other converters to extract stuff, e.g. EventsByScopeMapConverter) to be correctly registered when ambiguous converters already exist. Otherwise success depends on load order!