Unify the driveVelocity command using speed and spin
Refactoring to make a clear distinction when the Roomba Create is used
Added a class in progress (unused yet) before loosing track of it
Experiment with Protobuf Service: it confirms the initial decision that
it is not suitable.

- Code generated is not lightweight (need to implement a RPC controller
"a la Google"
- This functionality is indeed deprecated, so it is not good to start
building on it.
added notes for findbugs and Eclipse MAT
Implemented direct drive
Implement velocityDrive using directDrive and include validity check
Mark this class as untested
Adapt the test to use the locomotor interface (rather than direct
roomba) and take advantage of the new unified driveVelocity
Created a simple locomotor model to control Roomba in a more easy and
generic way
Simple test to verify the roomba locomotor model
computes the derived velocity/radius when the last command was a direct drive (rigth+left wheel speeds)
moved the socket thread safety in the client itself (it was before on the user side)
few more tests
adapted to use the unified driveVelocity and simplified using the Roomba locomotor model
Merge branch 'driveVelocity_unification'