Pass ROS/ROS2 messages across all available middleware

[fabawi]

Currently, ROS messages (std_msgs, geometry_msgs ..., + custom message types following the ROS topic/package mapping convention) can be published and received using ROS by setting the data structure to ROSMessage. There are multiple ways to make this happen, for example:

1. Add an argument e.g. (convert_to_native_object=True) to the ROSMessage publisher to convert the ROS messages to native objects. For non-ROS publishers, we can have a common lookup dictionart to identify supported type names across all middleware, and fallback to NativeObject when detected. This can cause problems, one being due to ROS nodes expecting messages of specific form can no longer deserialize the new types. Another issue occurs when convert_to_native_object is not set to True, meaning the object cannot be deserialized
2. Add ROSMessage listeners to all middleware. This would assume that the listener has ROS installed but would use the corresponding middleware for communication. The first issue with this approach is that it violates the goal of middleware separation and interdependence avoidance. Second, the objects would need to be deserialized locally (a huge issue with ROS2 since the serialization follows CDR, and messages need to be compiled), adding more overhead
3. Clone the message types and convert them to native Python/NumPy objects within classes. These class types would override ROS messages only when a non-ROS middleware is being used and default to ROS messages when used with ROS. This is probably the cleanest approach but requires much more effort to achieve since such classes need to be tested to not fail with all ROS message types. ROS2 is even more to design complex since most of the definitions are in the rcl C API
4. The quick and dirty approach is to install add-ons which do not necessarily install a fully functional ROS but just the parts needed for deserializing message types like rospypi/simple, which are not fully functional as ROS APIs. Still, could not find a ROS2 equivalent
5. Rely on websocket bridges? Don't think this is a good idea