Rename "Force" to "Actuation".

(to make naming more consistent and descriptive; including functions such as getForce, setForce,
computeOverrideForce, overrideForce, isForceOverriden, setOverrideForce, getOverrideForce)
It would be better if the interface was defined by Actuator and not ScalarActuator. `computeActuation(state)` should be what all actuators have to implement.  I avoided a templated Actuator class, to avoid confusion/difficulting in creating new Actuators, but now I feel the base does not provide enough structure and support. If the base where `template <int M, int N> class Actuator` where M was the number of controls and N was the actuation dimension then base Actuator could have all the machinery for specifying the actuation and speed cache variable as define power as Vec<N> actuation dot Vec<N> speed, as well as max and min controls. ScalarActutor would simply be an Actuator<1,1>. BodyActuator would be an Actuator<6,6>. The main reason for templating would be to enforce that whatever you call actuation and speed their product is guaranteed to produce power in Watts. For a muscle this would be tendon tension and the MTU lengthening speed. 

We are in a position to exploit Inputs and Outputs so that we have controls as `Input<Vector<double>>` and make the actuation and speed `Output<Vector>`'s having the same size (but potentially different from the controls). The question is should these controls be Vec<M> and Outputs Vec<N> where the size is defined at compile time? Alternatively. we could have Actuator<T> where we keep the controls structure as a Vector of controls sized at runtime (say by asking how many mobilities there are) and the Outputs are T where they can be double, SpatialVec (BodyActuator) or Vector (mobility forces) defined/specialized by the concrete type. This would enable having actuators that take two controls and create double actuation and speed.