Apply external link wrench for multiple steps

[diegoferigo]

PR #121 introduced the support to apply link wrenches. However, these wrenches are applied only for one physics step.

Often, environments run at a lower rate of the physics engine, and with the current situation from their loop they cannot apply external forces for more than one physics step.

I propose to create a new component, similar to ExternalWorldWrenchCmd, that also has a duration variable that specifies how long the wrench should be applied. Something like:

struct WorldWrenchWithDuration {
    msgs::Wrench wrench;
    std::chrono::duration<double> duration;
}

using ExternalWorldWrenchWithDurationCmd =
      Component<WorldWrenchWithDuration,
                class ExternalWorldWrenchWithDurationCmd,
                serializers::MsgSerializer>;

What's more difficult to choose, instead, is how to handle from above the case when an external wrench is already existing (i.e. its duration is still not expired) and the user wants to pass another external wrench.

Should the wrenches be summed together? In this case the duration could cause problems. In fact, the new component will be associated with the Link entity inside the ECM. We cannot insert multiple components of the same type linked to the same Entity. However, if the component stores a vector of WorldWrenchWithDuration, maybe we can sum them together:

using ExternalWorldWrenchWithDurationCmd =
      Component<std::vector<WorldWrenchWithDuration>,
                class ExternalWorldWrenchWithDurationCmd,
                serializers::MsgSerializer>;

The Physics system could handle the removal of the expired entries from the vector.

---

I am not really sure about this logic. In fact, it really depends on how the active physics engine handles external forces. Few will sum the new force to the previous one, few others instead will override the previous cmd. So, even if we handle this logic in the Physics system, it's not sure that the obtained behaviour is consistent. cc @traversaro

Moreover, in the case of the JointForceCmd component, if there are two systems that want to set a joint force, in the current upstream implementation the second one will override the first one if it doesn't check that someone else already has set a joint force cmd. This is still a very ambiguous behaviour of Ignition Gazebo, and we should keep in mind all these details to avoid encountering hard-to-debug bugs in the future.

[diegoferigo]

Implemented in #158. Closing.