Improving stretch_robot_free_process.py's effect on ROS2

[hello-binit]

Calling stretch_robot_free_process.py on a ROS2 worker works fine, but causes the driver threads and ROS2 launch wrapper to show tracebacks and other scary error logs to the terminal. There's two issues with this from a UX perspective:

1. If you didn't know that the stretch_robot_free_process.py CLI was called (e.g. it was in your .bashrc and opening a terminal called it, or if someone SSH-ed in a ran it as a prank), you wouldn't be able to interpret what happened from looking at the ROS2 console logs. You'd see a giant traceback and assume the driver experienced some failure. To make matters worse, ROS2's launch wapper hides all relevant tracebacks from the Python threads, so all you get is "Captured signal 15" from the threads, and the rest of the error (~100 lines) mislead you to look at ROS2 executors/etc.
2. Even if you did run the CLI yourself, the ROS2 launch file doesn't actually exit. It just kills the stretch_driver node, and leaves the robot_state_publisher and joint_state_publisher nodes running. If you then turn around a launch stretch_driver.launch.py again, now you have two instances of state publishers running. Killing stretch_driver should trigger the rest of the ROS2 launch to exit. This is similar to Launch files should exit with higher priority nodes exit #169