Add ActuatorCurrentLimit message.

Message type for setting the current limit for a group of actuators.

This is part of a larger set of interfaces that aim at exposing current limiting capabilities, and is yet another stab at what PRs #9 and #10 have proposed. Consider this a further iteration of these efforts.

#### Rationale

* A separate message type is convenient in the sense that it can be readily streamed via topic pub-sub, and can also be included in service req-rep, if needed.

* The message fields being arrays allows to specify current limits to one or more actuators, and mimics the structure of other ROS messages, like `sensor_msgs::JointState` and `trajectory_msgs::JointTrajectory`.

#### The big picture

The idea is to have the following interfaces (this PR deals with the first one only):

* **ROS message** `pal_control_msgs::ActuatorCurrentLimit`
* **ros_control types**
  * **Handle** `pal_ros_control::CurrentLimitHandle`
  ```c++
  class CurrentLimitHandle
  {
  public:
    CurrentLimitHandle();
    CurrentLimitHandle(const std::string& name, double* curr_lim);

    std::string getName() const;
    double      getCurrentLimit() const;
    void        setCurrentLimit(double curr_lim);
  };
  ```
  * **Interface** `pal_ros_control::CurrentLimitInterface`, which does not claim its resources
* **ros_control controller**
  * `pal_ros_controllers::CurrentLimitController`
  * Is configured from a yaml file with this structure
  ```yaml
    head_current_limit_controller:
    type: "pal_ros_controllers/CurrentLimitController"
    actuators:
      - head_1_motor
      - head_2_motor
  ```
  * Takes `pal_control_msgs::ActuatorCurrentLimit` commands  from a topic interface

#### Feedback needed

Apart from giving feedback on this particular PR, please also comment on the overall naming and structure of the other interfaces, as they should be coherent.

One particular aspect that I'm not decided on, is that the message name makes it explicit that we're dealing with actuators, while the `ros_control` side drops this identifier for brevity. What are your preferences?.

If we reach some consensus here, I can push to our private repo an implementation of the `ros_control` parts to our internal repo, while remaining compatible with existing code until we determine a migration path, if any.

@awesomebytes, @bmagyar, @lucamarchionni, @po1, @v-lopez 

Oops