Add option to output actuator_msgs/msg/Actuators instead of sensor_msgs/msg/JointState

[srmainwaring]

It would be useful to have the option to output the controller commands as actuator_msgs/msg/Actuators instead of sensor_msgs/msg/JointState.

The immediate application is for utilising the joint_state_topic_hardware_interface in conjunction with ros_gz in Gazebo simulation as an alternative to gz_ros2_control. ros_gz supports mappings from Gazebo -> ROS 2 for JointState, so populating the /robot_joint_states topic is implemented.

There is no convenient ROS 2 -> Gazebo mapping from JointState to a message type that can be used in the Gazebo joint controller systems, however there is a mapping for actuator_msgs/msg/Actuators. Providing the option to output this message would make integrating ros2_control with Gazebo models that are equipped with position and velocity joint controller systems straightforward and non-intrusive.

It also completely decouples the Gazebo simulation from ROS 2, that is it is not necessary to have ROS 2 installed on the machine running Gazebo as there is no plugin system dependency on ROS 2 in Gazebo in this arrangement. This is useful if say the ROS 2 system is running in a container, and Gazebo is running natively on the host (macOS for example). It also simplifies the process of switching between simulation and hardware configurations, as all the logic resides in the controller manager.

The alternative is to provide an additional node that relays JointState to Actuators. We'll need this in any case for testing, but it is less efficient than emitting the Actuators message directly.

[MarqRazz]

This sounds like a different hardware interface. The JointState hardware interface is specifically for JointState messages. Maybe we could create a base class that both of them depend on but the Actuator message sounds limiting because it only supports Position and Velocity without the ability to specify the joint names they apply to.