chore: refactor orchestrator and add more tests.

[thantos]

Closes #31

A start at refactoring the orchestrator.

1. Load
2. Execute
3. Persist

• Create a command executor which turns commands into events with client calls.
• Added tests for the command executor
• turns the core workflow execution into a generator
• Save ALL new events to dynamo instead of just the ones generated by the workflow execution
• Don't try to save events to dynamo from the activity worker
  • (worker -> sqs -> orchestrator -> dynamo)

[cfraz89]

would it help the runtime performance to move these nested functions - scheduleActivity, scheduleChildWorkflow, etc out of the nesting, into the root of the class? So they're not reconstructed every executeCommand, which might happen multiple times over the lifetime of an orchestrator instance?

[thantos]

The number of invocations is fairly constrained and each invocation represents one or more network call that would dwarf any additional function bindings.

My thought is that the code cleanliness provided by re-use of the scoped variables trumps the cost of the creating the function on the 1-20 times this function is called per workflow execution run.

[cfraz89]

Ok sure. I personally put nested functions in the negative-code-cleanliness category, but thats just subjective.

[sam-goodwin]

Why is the executor cleaner than the orchestrator? Looks mostly the same