Reactive easy full control

[mxgrey]

This PR significantly revises the implementation of the EasyFullControl API by making it reactive instead of running in a thread. It also tweaks the API itself in a way that I believe is much simpler for system integrators, especially for users of the Python bindings. I've also revised the API to be future-proof by using more PIMPL classes instead of basic data types.

In the process of testing this new API, I encountered pre-existing several bugs that had been reported before but were difficult to reproduce. This PR includes fixes for the following issues:

• [Other issue]: The robot does not move and generates a plan in a loop rmf#373
• two robots wait for each other for about 2.5 minutes when passing through one intersection rmf#356
• Crashing if a task auction happens while a robot is far from its navigation graph

I'm creating this as a separate PR that targets #235 so that reviewers can have a more clear idea of what changes are being introduced and why.

To test out this PR, it should be used in conjunction with open-rmf/rmf_demos#188

[xiyuoh]

Thanks for the revamp! Still testing the fleet adapter in various worlds and scenarios, so far it's looking really great.

A TODO that I found necessary in one of our use cases was making max_merge_waypoint_distance and max_merge_lane_distance configurable from the fleet's config.yaml, and then passing it to FleetConfiguration. Wondering if it's worth to add it at this time, happy to open a PR to this branch (or to the feature/easy_full_control branch after this PR is merged).

[mxgrey]

Sure, we can expose that in this PR. We might want to consider thinking of names that make their purpose more clear, but nothing comes to mind for me at the moment.

I'd suggest implementing it similarly to responsive_wait where there's a fleet wide default value and then a robot-specific override. If neither is specified then we fall back on the current hard-coded defaults.

For changing the values live we can add APIs to EasyRobotUpdateHandle. Currently the base RobotUpdateHandle doesn't use these parameters, so I don't think it would make sense to put them there.