Introduce waypoint trajectory RPCs

[hello-binit]

This PR introduces methods to command the stepper motors into following a waypoint trajectory. A "waypoint trajectory" is a spline that a stepper joint attempts to track over time. The joint position spline is defined by an series of waypoints, where each waypoint consists of:

• time from start of trajectory (seconds)
• joint position (radians)
• optional joint velocity (radians/sec)
• optional joint acceleration (radians/sec^2)

Between two waypoints is a segment of the spline. Given just time/pos, this segment is linear. Adding velocity, it's cubic, and with acceleration, it's quintic. Coefficients representing the segments are sent down to the stepper hardware. With full waypoints, each segment is defined by a quintic polynomial, f(t) = a0 + a1*t + a2*t^2 + a3*t^3 + a4*t^4 + a5*t^5; the coefficient array [a0, a1, a2, a3, a4, a5] is part of what is sent down to the hardware. A sample trajectory (used in the unit tests) is visualized on Desmos, and used to calculate the coefficient arrays of the segments.

This PR doesn't manage waypoints or compute segments from waypoints. It exposes an interface to the motors that accept the segments in a way that allows starting of a trajectory and preemption of the trajectory's next segment while a segment is actively being executed. The added methods are:

1. Start a waypoint trajectory with a segment: stepper.start_waypoint_trajectory([duration_s, a0, a1, a2, a3, a4, a5, segment_id])
2. Set the next segment of the trajectory: stepper.set_next_trajectory_segment([duration_s, a0, a1, a2, a3, a4, a5, segment_id])
   • This method is can be called many times in a loop while the previous segment is being executed, if preemption of the next segment is desired.
3. Stop an active waypoint trajectory immediately: stepper.stop_waypoint_trajectory()

The benefit of waypoint trajectories is that the joints can be commanded with planned trajectories that coordinate the whole body of Stretch into performing some coordinated action (e.g. when the arm, lift, and mobile base must arrive to specific positions at specific times in order to perform a grasp).

Finally, note that the firmware does not check the "executability" of a given segment. The hardware will attempt to track a given segment, even if it's waypoints form a malformed segment (e.g. exceeding joint limits, exceeding joint dynamics). Firmware checking of segment feasibility is now done in hello-robot/stretch_firmware#6.

---

TODO:

• Merge in Bugfix/remove sync timestamps #77
• Use stepper.set_first_trajectory_segment() instead
• Improve how active_id is tracked.
• Add firmware checking of segment "executability" and error reporting. Merge in Validate Waypoint trajectory segments #103

[aedsinger]

Tested against hello-robot/stretch_firmware#8 . Ran test_stepper unittest and all works well as expected.