Fix BlueROV IMU bridge for ArduSub SITL

[yeseorizi]

Summary

Restore the BlueROV2 IMU data path expected by ardupilot_gazebo and preserve the existing ROS-facing IMU topic.

Problem

The BlueROV2 SDF files explicitly published IMU data on /model/<namespace>/imu, while the ArduPilot Gazebo plugin subscribes to the sensor's fully scoped Gazebo topic:

/world/<world>/model/<namespace>/link/base_link/sensor/imu_sensor/imu

The two topics did not match. The ArduPilot plugin therefore received no IMU sample, returned empty sensor packets to ArduSub, and MAVROS remained disconnected with repeated No JSON sensor message received output.

The launch file also used the selected world filename rather than the world entity name declared inside the SDF (dave_ocean_waves.world declares oceans_waves).

Changes

• Remove the conflicting explicit IMU <topic> from all three BlueROV2 model variants.
• Read the actual world entity name from the selected world file.
• Pass that name through the robot upload launch path.
• Bridge the fully scoped Gazebo IMU topic and remap it to the existing ROS topic /model/<namespace>/imu.
• Wait for an actual IMU sample instead of treating topic advertisement alone as readiness.

Validation

Rebased onto ros2 after PR #65 and rebuilt dave_demos and dave_robot_models in an ARM64 Lyrical / Jetty container.

Both bluerov2 and bluerov2_heavy passed:

connected=true
imu_ok=true
odom_ok=true
stats_ok=true

The logs also contained:

Got HEARTBEAT, connected. FCU: ArduPilot
ArduPilot Ready

pre-commit run --all-files also passed.