Feature/quickster footstep provider

[stefanfasano]

This is the initial groundwork for the implementation of Quickster's footstep calculator into the regular walking controller via the CSG (in step generator thread).

Tests included in this PR:

• QFPTest; this tests switching between CSG modes while walking in place and standing in place

The next steps include:

• New message type to ensure things on the controller side know which CSG mode is in use
• Implementation into whole body MPC scheme
• Hardware testing on robot
• Max speed limits along with max acceleration per step

[christiandebuys]

I am confused by this boolean. Isn't whether or not you are executing the method inside onEntry() enough information to set firstTick in the method? Why are haveWeEntered and firstTick both in handleNewFootstep()?

[stefanfasano]

There's probably a better way to do this whole thing. They don't exactly convey the same information, since first tick could be false if it is the second+ tick or if it has not entered the state yet, and that distinction is important. It is possible for the method that relies on this boolean (handleNewFootstep()) to be called without entering the state (WalkingSingleSupportState) because I have this method tied to a listener in another class (WalkingMessageHandler), and the class that this method belongs to is instantiated twice, once for each leg. So it is possible for this to be called by the listener even if the class (and therefore single support of the proper leg) has not been called.

The thing is, this is probably redundant because I later ended up adding a check to make sure that we only proceed with the handleNewFootstep() method if we are on the proper side of the robot. So I can probably delete the logic that relies on haveWeEntered