Draft concept for injecting ros2_control hardware system

[danzimmerman]

This PR is inspired by the discussion on UniversalRobots#52 about further factoring out ros2_control here.

To allow maintaining the changes to <hardware> that are currently supported with conditional switching and many parameters that only apply to specific hardware implementations, I'm suggesting here to inject the <hardware> dependency from a top-level .urdf.xacro as a block param.

In ur_macro.xacro as it exists now, many of the numerous parameters required find their way into the conditional ROS 2 Control hardware definition, for example here for the real robot.

In this PR I tried to keep the conditional switching behavior in ur.urdf.xacro, so I define several optional <hardware> blocks there and pass them in to the xacro:ur_ros2_control macro as the block parameter ros2_control_hardware.

However, I imagine that this responsibility falling to consumer packages that use the ur_description macros instead, which would remove many parameters from ur_description calls, while keeping a single point of responsibility for loading and applying kinematics, physical, visual, joint limits, and other parameters that are more generic across real and fake hardware and simulations.

I made a simple example for ur_simulation_gazebo on my fork here.

A similar thing could be done inside ur_robot_driver, with a ur_real_robot.urdf.xacro, and maybe ur_description by itself would allow optionally instantiating a mock_system/GenericSystem.

I opened this PR to illustrate my suggestion, but it currently mixes in some work to pass through joint dynamics properties to fix broken joints in Gazebo Classic

Happy to split that out later if this approach is of interest.

[danzimmerman]

Reverted the joint dynamics changes to make this clearer.

[danzimmerman]

Maybe this doesn't make sense in the big picture beyond refactoring the package like UniversalRobots#52 when use cases outside of what ur_description currently supports are considered.

It would mean that ur_description or a ur_ros2_control package wouldn't need to conditionally switch hardware, but possibly that only really supports ur_simulation_gazebo, ur_simulation_ignition, ur_robot_driver and mock hardware, and it'd be easier for users who know what they're doing with ros2_control to specify everything completely in their own package.