feat: `ActionGraph` vs. `StateGraph`

Currently, the `.visualize()` method returns a graph where **actions** are nodes and **transitions** are edges. Parameters allow to display conditional edges and state values that are read/written. Let's call this the **action graph**. This helps understand the logic of the application and shows the previous/next action at runtime.

Here's an example:


Another relevant visualization would be the **state graph** where **state fields** are nodes and **actions** are edges. Currently, there are no visual tools to know all the **state fields** before execution. This puts emphasis on the dataflow of the application (converts a state machine graph to a dataflow, similar to Hamilton). During monitoring or debugging, we can number nodes with a `sequence_id` to know when it was last updated.

> This graph being confusing is not indicative of the value of the plot, but rather that simplification could be made. It becomes obvious that `feedback_history` is redundant with the many persisted instance of `feedback`

(This other graph structure is key to create rollback mechanisms. If the field `input_document` is updated on sequence `1` and `7`, and you want to rollback the value of `input_document` when at sequence `10`, we know we have to rollback to sequence `1` (or do some diff with `7` rather "undo" each step from 10 to 1)