File locking + Tool to free robot body

[hello-binit]

This PR improves the workflow for dealing with the "a Stretch Body process is already running" error. In the past, trying to run Stretch Body while an instance of Stretch Body was already running would result in the following errors/warnings:

[ERROR] [pimu]: Port /dev/hello-pimu is busy. Check if another Stretch Body process is already running
[WARNING] [pimu]: Unable to open serial port for device /dev/hello-pimu
[ERROR] [hello-motor-left-wheel]: Port /dev/hello-motor-left-wheel is busy. Check if another Stretch Body process is already running
[WARNING] [hello-motor-left-wheel]: Unable to open serial port for device /dev/hello-motor-left-wheel
[ERROR] [hello-motor-lift]: Port /dev/hello-motor-lift is busy. Check if another Stretch Body process is already running
[WARNING] [hello-motor-lift]: Unable to open serial port for device /dev/hello-motor-lift
[ERROR] [hello-motor-arm]: Port /dev/hello-motor-arm is busy. Check if another Stretch Body process is already running
[WARNING] [hello-motor-arm]: Unable to open serial port for device /dev/hello-motor-arm

For novice Stretch users, this output is scary looking and doesn't clearly communicate how to check if another process is already running (since often, that process is running in the background). Additionally, the Dynamixel classes are not lock protected, so the background Stretch Body instance will start to have trouble pinging the Dxls:

[WARNING] [tool_stretch_dex_wrist]: Dynamixel communication error during pull_status on tool_stretch_dex_wrist: 
[WARNING] [head]: Dynamixel communication error during pull_status on head: 
[WARNING] [head]: Dynamixel communication error during pull_status on head: 
[WARNING] [head]: Dynamixel communication error during pull_status on head: 
[WARNING] [head]: Dynamixel communication error during pull_status on head: 
[WARNING] [head]: Dynamixel communication error during pull_status on head: 
[WARNING] [head]: Dynamixel communication error during pull_status on head:
repeats indefinitely...

---

To improve on this workflow, using the Robot class from Stretch Body will now acquire a lock from the filesystem and write its process ID using the lock. If another Stretch Body instance has already claimed the lock, the following error is printed out:

Another process is already using Stretch. Try running "stretch_free_robot_process.py"

The new stretch_free_robot_process.py tool reads the process ID of the Stretch Body instance holding the lock and terminates the process. This is more reliable than using pkill -9 python or similar because it actually knows the process ID and won't be fooled if the process running Stretch Body doesn't have "python" in the name. Additionally, other python processes (e.g. hello_robot_lrf_off.py) won't get killed unintentionally.

At the moment, the lock is acquired in Robot.__init__() and released in Robot.stop(), but after bug #217 is fixed, the lock acquiring logic can be moved to Robot.startup().

Testing

Stretch 2 running Ubuntu 22.04. Tested with Stretch Body tools, iPython, ROS, ROS2, and more.