Multibeam color filter as a lookup table

[jp-pino]

Replace MultibeamConfig.color_filter (an index into palettes compiled into the fan renderer) with a MultibeamColorFilter message — bytes rgb, 768 bytes of R,G,B triplets indexed by echo intensity — plus SetMultibeamColorFilterReq/Rep and GetMultibeamColorFilterReq/Rep. The app can send a filter at any time; the drone keeps the last one in memory and uses grayscale until one is set (Get returns an empty rgb then).

Linked PRs (multibeam color filter — merge in dependency order)

1. Multibeam color filter as a lookup table #278 — MultibeamColorFilter + Set/Get requests
2. BluEye-Robotics/p2_msgs#43 — ROS message mirror (MultibeamColorFilter.msg)
3. BluEye-Robotics/p2_drone#998 — node_comm repliers publishing /multibeam/color_filter (ROS + tyndall IPC)
4. BluEye-Robotics/gst-sonar-renderer (merged to main) — elements read the IPC slot and follow changes
5. BluEye-Robotics/gst_rtsp_record#307 — sonar RTSP node (uses the renderer, no filter wiring needed)

The recorded-fan overlay (OverlayParameters.multibeam_enabled) is a separate set: #298, BluEye-Robotics/p2_msgs#54, BluEye-Robotics/p2_drone#1066, BluEye-Robotics/gst_rtsp_record#297. mbezoverlay picks the filter up from the same IPC slot once both have landed.

Color filter flows app → SetMultibeamColorFilterReq (768 bytes: 256 R,G,B triplets by echo intensity) → node_comm publishes /multibeam/color_filter → tyndall shared memory → mbezsrc/mbezoverlay poll it on start and on change. Greyscale until one is set; nothing is compiled into the renderer any more, so new app palettes need no drone rebuild.

Design note: the renderer reads the slot through the generated p2_msgs struct

The first cut mirrored the message with a local struct { uint8_t rgb[768]; } in the renderer to avoid a p2_msgs dependency. That cannot work: tyndall tags every shared-memory slot with a hash of the storage type name (typeinfo_hash(seq_lock<T>)) and asserts on mismatch when a second opener arrives, and the cross build has asserts on. The renderer therefore includes p2_msgs/msg/detail/multibeam_color_filter__struct.hpp (header-only, no ROS runtime linked) so both sides use the same p2_msgs::msg::MultibeamColorFilter type. Consequence: the message must stay trivially copyable and exactly uint8[768] (static_asserted in the renderer).