Add vision-based route costmap from YOLOPv2 drivable-area segmentation

[siddarthnandy]

Summary

Adds a second, vision-based route costmap alongside the existing planned-path-distance costmap (costs/route_costmap_node), built from YOLOPv2's drivable-area segmentation head rather than the planned route path.

• yolopv2_drivable_grid_node — projects a drivable-area segmentation mask (/drivable_mask/front) into the shared BEV grid using a camera-to-ground-plane ray-cast lookup table (bev_geometry.CamLUT). Publishes to /grid/drivable/segmented_v3, alongside the existing PSPNet-based /grid/drivable/segmented, for live side-by-side comparison.
• route_costmap_v2_node — turns that projection into a graded route-planning cost grid on /route_costmap/segmented_v2: lowest cost at the lane center, rising toward the edges, fully non-drivable outside the lane. This is a second, independent cost source from the existing costs/route_costmap_node (which costs distance to the planned path) — kept side by side for comparison, not a replacement.

The robustness logic behind route_costmap_v2_node lives in lane_costmap.py, unit-tested independently of ROS:

• seeded_connected_mask — keeps only the connected component touching the vehicle's own grid cell, dropping disconnected noise islands or an unrelated lane picked up elsewhere in the frame.
• RollingMajorityFilter — a short, fixed-length window of recent per-cell masks with a majority vote, so a few frames of the model briefly bleeding into an adjacent lane can't reach the output, while a real sustained change still wins within a fraction of a second.
• distance_cost_grid — a distance transform on the robust region turns it directly into a 0-100 cost field; the lane center falls out for free as whichever cell is farthest from every edge, with no separate centerline-tracking step.

Dependency note

Both new nodes import bev_geometry.CamLUT and subscribe to /drivable_mask/front, both introduced in #505 (not yet merged). This PR does not duplicate any of #505's files — it only adds the 4 new files above plus the minimal registration lines in setup.py and the launch files. Until #505 merges, these two nodes build and start cleanly but idle (no bev_geometry module / no mask to consume yet); once #505 lands, they become fully functional with no further changes needed here.