Rethink what information we need in the Work Order

[Yadunund]

At present, the ROS entrypoint when submitting a job, ie the [WorkOrder ROS msg](https://github.com/osrf/nexus/blob/main/nexus_msgs/nexus_orchestrator_msgs/msg/WorkOrder.msg#L5, has a string work_order field that can take arbitrary serialized data that describes a work order. This was done to keep the schema flexible. However the internal implementations, specifically within the system orchestrator parse the string into a WorkOrder object.

We need to rethink how we want to define Work Orders. The current model atleast had a lot of use case specific parameters (SkuId, quantityPerPallet, unit etc).

imo the minimum parameters are

• work_order_id : A globally unique ID assigned to the work order.
• A list of steps where each step defines
  • process: that needs to run (for now we can consider keeping this as a unique process name string)
  • parameters: Additional constraints to parameterize the process
  • inputs: Materials needed from outside the workcell (WIP items, raw materials etc)
  • outputs: Materials resulting from the process.

A philosophical question to answer is whether the material inputs/outputs should be in the work order definition. If we have standardized definitions of processes in the system, we could leave it to the individual workcells or a different dedicated service to figure out how move material between workcells based on matching inputs/outputs. But that is a separate discussion.

For now defining inputs and outputs fields and a way to specify linking between outputs of one workcell to the inputs of next will be essential to define transportation requests (ie, to construct the sequence of Pickup->Dropoff phases required).

Slightly tangential; while the original goal was to support different work order schemas, the currently implementation is only capable of loading the one model we have. Alternatively, we get rid of the concept of models and update the WorkOrder ROS msg to explictly adopt a schema.