Port the lunar pole exploration rover plugins and model to Gazebo Harmonic, keeping Fortress (closes #47)

[asimonov]

Closes #47.

Makes the lunar pole exploration rover's power system plugins and model build and run on Gazebo Harmonic / ROS 2 Jazzy while keeping Ignition Fortress / ROS 2 Humble working. Two commits:

1. Build the Gazebo plugins for Harmonic as well as Fortress — SolarPanelPlugin, RechargeableBatteryPlugin, SensorPowerSystemPlugin and RadioisotopeThermalGeneratorPlugin now target the gz-sim 8 API (gz::sim / gz::rendering / gz::sensors, gz/ headers, GZ_ADD_PLUGIN, gz* console macros, per-message includes for gz-msgs 10). Fortress ships gz/ redirect headers for all of those namespaces but not for the GZ_ / gz prefixed macros, so a 60-line plugins/gz_compat.hh maps those onto their Ignition names when absent. One source tree builds on both; CMakeLists.txt and package.xml pick the Ignition system packages on Humble and the ROS gz_*_vendor packages otherwise (so on Jazzy the plugins link against the same libraries as ros_gz and gz_ros2_control), and the environment hook sets both IGN_GAZEBO_* and GZ_SIM_* paths so Harmonic finds the meshes and plugins (the hook part of Update to Gazebo Harmonic/Jazzy #36). Since Building packages on jazzy that include simulation breaks due to missing humble dependencies #41 the plugins were excluded from non-Humble builds; this makes them available again.
2. Make the lunar pole rover model work on Fortress and Harmonic — xacro properties keyed on ROS_DISTRO select ign_ros2_control/IgnitionSystem + ignition-gazebo-*-system or gz_ros2_control/GazeboSimSystem + gz-sim-*-system, so the one model serves both the existing Humble demo and the Jazzy one. The rover's controller configuration also moves here, next to the model, instead of being referenced through $(find lunar_pole_exploration_rover) in the demos repository (as the curiosity rover's is).

The canadarm, curiosity and lunar terrain models are untouched. Running the ported SolarPanelPlugin on Harmonic exposes a thread-safety bug in it (#44); the fix is a separate PR stacked on this one, and the Jazzy demo (space-ros/demos#165) needs both.

Effect on consumers

Every demo that builds this package on Jazzy (space_robots, lunar_terrain) previously got a simulation package with no plugins; it now compiles the four plugins as well, which adds well under a minute to the build and declares gz_{sim,plugin,common,rendering,sensors}_vendor as dependencies — the same vendor stack both demos already pull in for ros_gz and gz_ros2_control (space_robots builds those from source; lunar_terrain installs ros-jazzy-ros-gz), so no new class of dependency. Nothing those demos take from the package (the model directories) changes. On Humble (lunar_pole_exploration_rover on main) the build is the same as before.

Checked by building the current demos main Dockerfiles of all three against this branch plus the #44 fix (arm64, one edit each to clone the branch instead of main): lunar_pole_exploration_rover on Humble (67 packages), space_robots (53 packages) and lunar_terrain (11 packages) all build clean. The Humble image was also run headless: the server stays up with all four plugins loaded from the image build, the solar panel publishes ~106.7 W and the battery 30 V / 100 %, with no crash output.

Verification on Harmonic

With the #44 fix on top, the Jazzy demo from space-ros/demos#165 built against this branch and run headless (gz sim -s --headless-rendering): all four ros2_control controllers active, the rover drives and rotates through the demo services, the left solar panel reports 106.786 W at rest (the same reading the Fortress build gives) and rises to ~129 W as the rover turns, the battery reports 30 V / 100 %, the sensor activation switches change the power consumption, and all eight 2048x2048 mono16 cameras deliver frames. Every topic, service, joint and frame in the demo README was checked against a live run with the GUI.