Safety controller behavior; add a "no-backward" option

[corot]

Following complains from OSRF people... The controller would just block forward commands until the bumper gets released or cliff is not detected anymore. Doesn't fit easily in our current velocity multiplexer-centered architecture, so we should reorganize it, for example by using the safety controller to "filter" muxer's output and no as the highest priority input.

[sebasgm85]

One related issue is that currently it is difficult to add objects to the navigation costmap with Turtlebot if safety_controler is enabled because the bumper needs to be pressed for a while in order to add the object, and the safety_controller moves it backwards instantaneously.

One simple solution could be this no-backwards option, but also could be a delayed-backwards option, or maybe just find the way for safety_controller and the navigation stack to detect the bump at the same time.

[corot]

Yes, I realized this... it's fixed on hydro-devel (ac8d210631e78453df3704d39bbaac77706fc291), but as it is a big change in the code I preferred not to release it on groovy.

[stonier]

Better explanation, that commit above makes sure it sends a continuous single while pressed instead of a change of state notification only. That should make the navigation costmap easier. We'll delay other behaviour for now until we really need it.