First prototype of motion planning support.

- Add dependencies on MoveIt!
- Add helper class that plans an approach trajectory when needed, and is able to
  reason about which planning groups to use
- Pending tasks documented as inline TODOs
Refactor approach computation internals.

Planning group selection has been improved to select groups that:

- Span at least the joint of the input motion that change between current and
  goal configurations.

- Span at most all joints of the input motion.
Proper support for setting waypoint vel, acc.

- Expose acceleration field through PlayMotion and MoveJointGroup.

- In MoveJointGroup, don't set zero velocity if unspecified. Since we now have
  the populateVelocities method, it's already being taken care of there.
Action goal fails when approach computation fails.

- Fix for bug where goal remained active indefinitely.
Log message aesthetics. Caps, better messages.
Silence cppcheck warning.

- Type qualifiers ignored on function return type [-Wignored-qualifiers]:
  Function expecting const int returned int.
Make planning optional. Deprecate reach_time.

- The action message has a new field: skip_planning, used to request for no
  motion planning to take place, case in which the approach time is
  automatically computed from a specified maximum velocity.

- The above point means that the reach_time parameter is no longer required,
  hence has been removed from the action goal message.

- A side-effect of this, is that the reach_time is computed by the approach
  planner, and no longer has to be forwarded all the way down to the
  MoveJointGroup instances.
Fix crash when approach planner requisites not met

- If the required rosparam config is absent, print a descriptive error and
  don't crash.
Make tests build.

- Adapt test logic to new message layout.

- Tests currently don't run successfully, as rrbot doesn't yet have a MoveIt!
  configuration.
Isolate move_group async spinner from rest of node

Without this change, the synchronous spinning of play_motion was compromised.
Now play_motion preserves its synchronous spin behavior, and move_group
instances share a separate asynchronously serviced callback queue.

This changeset can be considered an initial fix for #31: When canceling a goal,
the cancel request will block until planning completes, but will then be
serviced correctly. The current planning latencies are small enough to make this
solution acceptable.