[Fastroof]

Closes #64

What and why

A simulation shared by several robots (the arena of the KPI Rover hub) needs every robot under its own name.
sim_robot.launch.py gets two launch arguments; with the defaults the single-robot simulation is unchanged.

• robot_ns (default empty): names the Gazebo model, prefixes the Gazebo topics of the lidar and the IMU and is the
  namespace of the controller manager (gz_ros2_control). The controller manager topics (robot_description,
  joint_states, diff_drive_controller/cmd_vel, diff_drive_controller/odom) move under /<robot_ns>, so
  robot_ns works with what runs the shared simulation and bridges them. /scan, /imu_broadcaster/imu, /clock
  and the frames stay the same.
• load_controllers (default true): false leaves loading the controllers to the shared simulation.
• kpi_rover_controllers.yaml matches the controller manager in any namespace (/**/), and
  tf_frame_prefix_enable: false keeps the frames odom / base_footprint. The real robot (hw.launch.py) uses
  the same file without a namespace: nothing changes for it.
• gz_bridge.yaml: absolute ROS topic names, the bridge runs in the namespace and expands only the Gazebo topics.

How it was tested

• simulation
• real robot (overlay or branch image)

Simulation:

• sim.launch.py world:=empty without robot_ns: the controllers are active, the robot drives (/odom vx 0.3
  at /cmd_vel 0.3), /scan comes in laser_frame.
• Hub arena (garden world): two robots with robot_ns:=<login> load_controllers:=false, separate topics, RTF 1.0,
  a robot is removed from the arena when its launch stops.

Real robot: not tested. hw.launch.py gets only the /**/ keys and tf_frame_prefix_enable: false in the controller
config, which give the same names and frames without a namespace.

Checklist

• One topic per PR
• README / docs updated if the behaviour or the usage changed
• Breaking change (topics, parameters, launch arguments used by applications) is marked with ! in the title