Fallback to implicit serialization for diagram operations

[mxgrey]

The implementation of dynamic workflows in #27 requires users to explicitly register which operations their type is able to do.

For types that can be both serialized and deserialized, it should be possible to support all operations by falling back on their serialized forms, even if the user did not explicitly register compatibility with the operation.

[mxgrey]

In reference to this comment one alternative I'd be open to considering is introducing an explicit serialize_response option to turn the node output into serde_json::Value. Then we might see something like this:

{
    "start": "fork",
    "ops": {
        "fork": {
            "type": "fork_clone",
            "next": ["get_position", "get_yaw"]
        },
        "get_position": {
            "type": "node",
            "builder": "get_robot_position",
            "serialize_response": true,
            "next": "join"
        },
        "get_yaw": {
            "type": "node",
            "builder": "get_robot_yaw",
            "serialize_response": true,
            "next": "join"
        },
        "join": {
            "type": "join",
            "next": "make_pose"
        },
        "make_pose": {
            "type": "transform",
            "cel": "<script that reads position and yaw data to make a pose>",
            "next": "go_to_place"
        },
        "go_to_place": {
            "type": "node",
            "builder": "go_to_place",
            "next": "terminate"
        }
    }
}

At that point we can leave it to the GUI to advise the user on when "serialize": true may be needed and/or insert it automatically in a way that the user can override.