Add api for robot charging tasks

[luca-della-vedova]

New feature implementation

Implemented feature

Closes #261.

Implementation description

This PR adds support for submitting robot charging requests through a charge task.
This task should only be used in direct task requests, since dispatching it to the robot that can charge the fastest doesn't really make a lot of sense. addressed in d87b87b

It can be tested with this rmf_demos branch that adds a dispatch_charge task, with mandatory fleet and robot parameters to make sure it is a direct assignment.

[mxgrey]

I recommend we add "Battery" everywhere to make this more explicit, e.g. "Charge Battery Event", event_description__charge_battery.json, "Charge the battery of a robot".

If anyone develops a bull robot for a rodeo they might want "charge" to mean something else.

[luca-della-vedova]

99304d6

[luca-della-vedova]

In d87b87b an unordered_set<std::string> has been added to be checked when bidding for tasks to make sure fleet adapters don't bid on charge_battery tasks. Now charge_battery tasks can only be submitted through direct assignment and bidding will fail.
TODOs have been left in place to expose this as a parameter, for system integrators to choose which tasks they want to accept as direct but don't want to bid on.

[Yadunund]

I don't think we necessarily need this event_description schema since we don't support any ChargeBattery events in rmf_task.
With this description, users can theoretically submit a composable task with a ChargeBattery event injected between other activities but the fleet adapter will not find the right builder from rmf_task_sequence to generate the Model and Description for this event.

Not a blocker imo but it would be good to test what happens when such a compose task is submitted to make sure any errors are gracefully handled.

[Yadunund]

I think right now the battery level to which the robot charges up to is statically defined in the fleet config. In the future it would be good to specify this % in the properties here and have the TaskPlanner accept this value in the Options it receives before it plans. Not a blocker.