Use resource manager

[Karsten1987]

Last part of #164 and closes #164

Currently sits on top of #216 and addresses the comment in here.

To start the node one can pass in a URDF as such:

ros2 run controller_manager ros2_control_node --ros-args -p update_rate:=10 -p "robot_description:=`cat install/test_robot_hardware/share/test_robot_hardware/test_robot_hardware.urdf`"

[Karsten1987]

Introduced a common URDF within the test_robot_hardware package, which reflects and exports all three types of hardware components.
The system can be loaded as such:

ros2 run controller_manager ros2_control_node --ros-args -p update_rate:=10 -p "robot_description:=`cat install/test_robot_hardware/share/test_robot_hardware/test_robot_hardware.urdf`"

Once the file is loaded, the system can be probed via a service call:

 ➭ ros2 control list_interfaces
command interfaces
	 base_joint/position
	 joint1/position
	 joint2/position
state interfaces
	 base_joint/position
	 ft_sensor/fx
	 ft_sensor/fy
	 ft_sensor/fz
	 ft_sensor/tx
	 ft_sensor/ty
	 ft_sensor/tz
	 joint1/position
	 joint2/position

[destogl]

@Karsten1987 Thanks for this!

I updated the demo example in ros2_controls/ros2_control_demos#37 to work with this.
Also, I changed the forward_command_controller to work.

To check the demo see README instructions.

I had to create a cusom branches since I did small changes to this PR in #240 and a small chnage to joint_state_controller (see comment in ros-controls/ros2_controllers#109)

[Karsten1987]

I am finally putting this up for review. I've remodeled the controller manager and resource manager to load the hardware dynamically. That also revokes the dependency on the test_robot_hardware package, which could then eventually be reworked to store a common set of test materials, such as test controllers, test hardware components and their URDFs.

Please be aware that this PR will break the existing controller interfaces and all controllers within ros2_controllers.

[destogl]

I am happy now :)
Thanks!

[bmagyar]

What are the plans with the packages the build is broken on?

[destogl]

I see only an issue with joint_limits_interface. transmission_interface will change anyway and it should be kind of independent from all this.

Are there any other issues you see?

[Karsten1987]

I think that the joint limit interface can safely be ignored for now. I believe that we actually don't need a dedicated package for this. The functionality can easily be incorporated within either the hardware_interface or into a default component package. Interface seems to be wrong in this case then.

[guru-florida]

I updated the code for joint limit interface in PR #271. Discussion about moving these files into hardware_interface is in there.

I think that the joint limit interface can safely be ignored for now. I believe that we actually don't need a dedicated package for this. The functionality can easily be incorporated within either the hardware_interface or into a default component package. Interface seems to be wrong in this case then.