ICRA 2015 Integration tests and a more accurate motor model

This pull request contains three main parts:

1) Some preliminary work I've been doing to create CPG classes with feedback (untested)

2) Integration tests for the ICRA 2015 paper

3) A replacement for tgLinearString that uses a realistic motor model.

Regarding 3: as I was testing I noticed a _huge_ difference in performance for my 6WCSCM spine data based on the simulation's timestep (50% improvement at 500 Hz vs 1000 Hz). After some investigation, I determined the way I implemented acceleration constraints in tgLinearString two years ago was completely wrong. Rather than limiting acceleration (change in velocity), I just set a second limit of dLength for a given timestep. At small timesteps, this second limit gets enforced exclusively (since dt is squared in the implementation). I realized that in order to get around this, I have to explicitly represent actuator speed somewhere. The easiest way to do this was to finally get around to writing that motor model we've talked about off and on for a while.

Thus tgKinematicString. This introduces a radius, inertia, and motor friction parameter to the string model, and semi-implicitly integrates velocity and position over time. The torque provided by the tension actually affects the dynamics of the rest length, and there is an option to make the motor backdrivable if the specified torque isn't enough. I implemented a linear torque-speed curve using the specified maximum force and velocity. This matches many of the abstracted models I found online for brushless motors (max torque at zero speed). Obviously users can subclass to make their own torque speed curves.

In order to use this class, we now need to worry about low level PID control on the motor. I implemented simple p controllers on position and tension (replacing moveMotors and tensionMinLengthController, respectively), and they suffer from all of the typical problems with P control. I'll work on getting these into the motor model parameters tomorrow, or maybe make a PID controller class.

And in a simple example (AppTimestepTest in my dev folder), this does solve the timestep independence problem, within rounding error. I'll make an integration test tomorrow as well.

This pull request addresses half of #8. Other fun things that could extend this model eventually - maximum length reversing the sign convention on velocity for when we "run out of string." The current sign convention assumes a counter-clockwise wind (positive angular velocity lengthens).