Remove with DSL. steps is optional.
trying to split Step and StepExecution

still a work in progress

Reference: https://trello.com/c/QFTIBCof/82-need-stepfactory
trying to split Step and StepExecution

still a work in progress

Reference: https://trello.com/c/QFTIBCof/82-need-stepfactory
Execution type needs to be available in Descriptor

... because this is where we compute necessary context types
support subtyping in Step better
Split Step and StepExecution
Keep track of active StepExecution
Not sure how to fix them up correctly, so just leaving TODO comment for now
Use StepExecution to persist state during the async execution.

Still more changes need to be made to eliminate static 'runningTasks' field
Minor tidyness changes
We want FlowExecution to be able to list active StepExecutions

... for example so that we can cancel them. This is also needed to provide system-wide enumeration of the running StepExecutions
Track all the running FlowExecutions in the system.

This serves multple purposes, including proactively resuming them upon start as well as list up all the StepExecutions indirectly
Implementing asynchronous enumeration of all StepExecutions in the system.

And the corresponding provider in Workflow. The idea is to use this in DurableTaskStepExecution et al to simplify those implementations that track long running activities
Move to StepExecution to make discovery easier
already implemented as stop()
Implement cancellation of DurableTaskStepExecution.

Given that there'll be numerous StepExecution implementations, it's better to have the caller handle exceptions.
Fixing persistence based on test failures
More persistence fix based on test failures
Making IntelliJ compiler happy
atomically update the file