feat: add XYZI sensor type and parameterize topics/frame (upstream PR #4)

[h-wata]

Summary

Ports the changes from upstream leggedrobotics#4 (by @jeldriks) onto this fork's main, which has already diverged with fork-local commits (TinyXML2 migration, SensorDataQoS BEST_EFFORT, static lib export).

• Adds robot_description_topic parameter: subscribes to /robot_description (transient-local) and picks it up automatically from robot_state_publisher when the robot_description parameter is left empty; the parameter still takes priority when non-empty. If nothing arrives, the node logs a WARN every 10 seconds until it does.
• Adds sensor_frame as a launch argument (previously only settable via the filter_config YAML).
• Adds out_pointcloud_topic as a real node parameter (used directly for the publisher topic), replacing the previous /cloud_out launch-file remap. in_pointcloud_topic was already parameterized on this fork.
• Adds Generic XYZI (pcl::PointXYZI) sensor type as lidar_sensor_type=6, including the corresponding shape-publishing branch in cloudCallback (upstream PR Subscribe to /robot_description, provide sensor_frame via launch file and add XYZI sensor type leggedrobotics/robot_self_filter#4 only added the sensor construction case + one shape-publishing case in a base that predates this fork's Ouster/Hesai/Robosense/Pandar additions).
• Updates README and package.xml/CMakeLists.txt (std_msgs dependency for the description-topic subscription).

filter_config YAML vs. launch arguments

sensor_frame, in_pointcloud_topic, out_pointcloud_topic, lidar_sensor_type, robot_description_topic, and zero_for_removed_points follow this priority: an explicit CLI argument (e.g. sensor_frame:=...) wins, otherwise filter_config YAML wins, otherwise the node's own declared default applies. This is implemented by passing filter_config and any explicit CLI overrides through the same arguments= list, in that order — a -p key:=value argument only beats a --params-file argument for the same key when it comes after it in the same --ros-args block, and --params-file entries otherwise resolve by plain last-one-wins regardless of whether the key is node-specific or wildcard-scoped. String-valued overrides are quoted (-p key:="value") so a numeric- or bool-looking CLI value (e.g. sensor_frame:=123) is passed as a string instead of crashing the node with InvalidParameterTypeException.

robot_description and use_sim_time are the two exceptions — the launch argument always wins over filter_config for these:

• robot_description can be an arbitrarily large, multi-line URDF/XACRO string. -p's value is parsed as a YAML plain scalar, which folds embedded newlines into spaces and would silently corrupt it, so this key is excluded from the CLI-override mechanism above.
• use_sim_time is a cross-cutting runtime setting expected to be driven by the overall launch context, not by a per-filter config file.

Disclosed default change: when neither filter_config nor the CLI sets zero_for_removed_points or lidar_sensor_type, this launch file used to force true / 2 (Ouster) unconditionally regardless of what filter_config said. It now falls through to the node's own declared default (false / 0, XYZ) like every other parameter above, restoring filter_config's authority. A launch invocation that omitted these and relied on the old forced values will observe different behavior. If lidar_sensor_type falls through to its default this way, the node logs a WARN at startup, since silently defaulting to XYZ drops extra fields (intensity, ring, etc.) from sensor types that have them.

Breaking change

This PR removes the launch argument description_name and replaces it with robot_description_topic. Callers passing description_name:=... are affected.

Compatibility with fork-local commits

• TinyXML2 migration (bcff853) and static lib export (8910134): untouched, no overlap (self_filter.cpp doesn't touch XML parsing).
• QoS BEST_EFFORT (3826a6c): preserved. The publisher still uses rclcpp::SensorDataQoS(); out_pointcloud_topic is layered on top of it instead of reverting to upstream's remap-based approach.

Verification

All of the following were run against an isolated colcon build (--build-base/--install-base outside the shared workspace build dir, --cmake-force-configure) of this branch's actual binary, not inferred from reading the code:

• colcon build: succeeds, no tests defined (pre-existing).
• XYZI (lidar_sensor_type:=6) and XYZ (lidar_sensor_type:=0, default) both start cleanly with a minimal inline URDF, no "sensor type not handled" errors.
• For each of the 6 CLI-override keys: YAML-only (no CLI arg) yields the YAML value; explicit CLI yields the CLI value; neither set yields the node's own default. Confirmed this regressed at parent commits before each fix and passes at the current head.
• sensor_frame:=123 starts the node successfully with sensor_frame as the string "123", not a crash.
• robot_description_topic set via YAML is reflected in the periodic /robot_description-wait WARN message, not the node's default topic name.
• lidar_sensor_type unset (neither YAML nor CLI): WARN logged at startup. Set via YAML or CLI: no WARN. Confirmed this WARN is absent at the parent commit (gate not yet present).

Credit: based on upstream PR leggedrobotics#4 by @jeldriks.

---

Ready for re-review.