WIP: Plugin-based simulator

[marip8]

This PR adds a plugin-based simulator for using gl_depth_sim components. There are two types of plugins: SceneUpdaterPlugin and RenderPlugin. The SceneUpdaterPlugin is responsible for maintaining the renderable scene by creating a map of RenderableObjectState objects and updating their positions. The RenderPlugin accepts a copy of this map from the SceneUpdaterPlugin and generates a form of rendered display using gl_depth_sim components. This PR implements these interfaces by providing a plugin that can create a scene from URDF and update with TF information, a plugin that renders the scene as a 3D depth camera, and a plugin that renders the scene as a laser scanner.

TODO:

• [ ] Update creation of GL windows/buffers such that multiple instances of the SimDepthCamera with different camera properties can exist at the same time

@schornakj can you review the content and structure of this PR and advise on how it fits into your vision for a pure CMake package?

[schornakj]

@marip8 In general there isn't a good way to provide ROS-agnostic support for ROS nodes, publishers/subscribers, tf2 listeners, and XmlRpc values. One way to work around this would be to create separate repos for ROS-dependent functionality and leave this repo as an independent core library. This is how the Tesseract repos are structured and it seems to be working OK (there are three: tesseract, tesseract_ros, and tesseract_ros2).

I'm less inclined to mix ROS versions within the same repo, since this complicates documentation, issue reporting, and CI. I was able to slice out the ROS1 demo node into a separate optional package within the same repo in my pure-CMake PR, but I had to (for example) make all the individual dependencies in its package.xml conditional on the detected ROS version, which is rather messy.

Maybe we could make a gl_depth_sim_ros repo in swri-robotics for the library and nodes you're adding here, an eventually we could also add gl_depth_sim_ros2 to provide equivalent functionality in ROS2.

[marip8]

What do you think of leaving the ~~simulator executable and~~ plugin interface definitions in this repository since they are ROS-independent C++ classes? Then I could make a separate repository for the ROS1 plugin implementations

[schornakj]

I'd need to investigate how ROS2 handles plugins, since simulator_plugins.h uses an XmlRpcValue which I think is a ROS1-exclusive thing. The changes you've made to sim_depth_camera.cpp look good and are certainly independent of ROS. The sensor-specific plugins are pretty minimalist so I don't think it would be a big deal to have duplicate ROS1/ROS2 implementations of them in dependent packages.