Support ROS action features

[hjsuh94]

As @weigao95 pointed out, it would be better to have the server reply that it got the plan, and then reply again when it finishes the plan.

This might change the state machine architecture?

---

TODOs:

• support WaitForServer in the client, which blocks until the server is in state IDLE.
• Move zmq_client out of the examples folder and make it part of the core API. It should accept lcm messages of our own plan message type. zmq_client should load zmq socket and channel names from the same config file as IiwaPlanManager.
• publish ZMQ messages so that they can be recorded by lcm-spy.
• PLAN_STATUS doesn't distinguish between a successful plan and an aborted plan. If we need to distinguish between them (do we?), a lock-protected variable would be needed to communicate this information from the abort thread to the ReceivePlan thread.
• client.wait_for_result may return the result of the previous plan if called right after the previous plan finishes, a problem observed here. The solution is to publish both the plan signature and plan status on PLAN_STATUS channel. Resolved by Mimic ros action #24.

[pangtao22]

Wei's feedback suggests that it might make sense to mimic the workflow of ros actions, which will lead to changes in the state machine logic. Before writing any code, it's worthwhile to think carefully about the implications for both trajectory and streaming plans, and how Schunk commands are handled.

Notable features of ROS actions that are missing from our current implementation include:

• A function that blocks the client until the server is up and running.
• The client is not blocked after sending the plan to the server. Instead, the client can optionally call a WaitForActionToFinish function that blocks the client until the action finishes.
• The client can also send a command to cancel the current plan.