[middleware/pocolibs] Adapt to velodyne-1.4 interface
[ros overlays] JointTrajectoryAction is now available in control_msgs
[human builder] Use standard armature/armature pose

Instead of the 'LAAS centric' HumanPosture (which is still used with the
pocolibs middleware).

Also, the armature sensor is now automatically added. This issue has been reported
by Omar Adair Islas Ramírez on the mailing list.
[ros] {ROSReader->ROSSubscriber}

Be more consistent with ROS terminology.

Reported by Diego Escudero
[ros] Prevent registering ROS services with no explicit type

The type is expected to be set with @ros_service(type=...).
This replace previous behaviour where ROS service would default
to (the most useless) 'MorseAnyService'. Cf commit 07ac80117a162ce for details.

Reported by Diego Escudero
{ROS,Yarp,... -> ROSDatastreamManager,YarpDatastreamManager,...}

Refactoring of datastream manager name, to match the 'xxxRequestManager'
terminology. As a side effect, it prevents confusion between a
'core.datastream.Datastream' (renamed into DatastreamManager) and
a 'middleware.abstract_datastream.AbstractDatastream' which are two
unreleated objects.

Reported by Diego Escudero.
[ros] Documented where ROS serialization/deserialization actually takes place

Reported by Diego Escudero.
[pymorse] Added a check for invalid component names

If a component name does not contain the full hierarchy of the robot,
it's  a bug in the MORSE cmpt renaming code
[builder] Removed builder.creator.RobotCreator

This class simply created an empty robot, but was broken because
the resulting component did not inherit of builder.Robot (one of the
consequences is that a RobotCreator instance is not considered for
automatic renaming).

Better to remove it completely.
Now, when creating a robot *without a Blender model*, an Empty is added.
This makes the FakeRobot (the only user of RobotCreator) a real robot, and
should fix bugs (because, as a RobotCreator instance, it was not considered
for automatic renaming, and thus its sensors/actuators would not be
accessible from pymorse for instance).
[core] Add a FreeZ property to robot

It will change slightly the behaviour of apply_speed for dynamic robot.
It exists already in waypoint actuator, and will be removed from it
[core] Move apply_speed from actuator to robot

It seems more logic to have it at robot level. It is more symetric with
apply_vw_wheels on wheeled_robot. And it will be soon depends of some
properties of the robot.

Update the different caller
[core] Handle apply_speed properly with robot with free_z and dynamic
[builder] Introduce set_{rigid_body, no_collision} to configure robots
[builder] Make RMax a dynamic robot
[testing] Add a test for velocity control for rmax
[testing] Add an actuator on RMax for NED test so it maintains the robot position
[core] Introduce robot::force_position and use it (orientation, teleportation)

It handles the black dance against {restore,suspend}Physics,
linearVelocity and gravity handling. Guessed from a lot of Blender code
reading
[testing] Add a basic test for submarine robot
[actuator] Fix destination actuator to work in 'velocity' mode
[data] Remove logic from submarine