Continuation epochs

this PR adds FSM managed 'workflowEpoch' and 'startedEventID' fields to the `SerializedState` struct. The workflow epoch is a counter of the number of times a workflow has been continuedAsNew, and the startedEventID is the id of the decision task that generated an updated `SerializedState`.  

The payload of the PutRecord call to kinesis when replicating state, is the current `SerializedState` struct as json, so consumers of the kinesis stream can calculate a total ordering of state changes for a given workflow by ordering the messages by workflowEpoch and startedEventID.

We also add the handling of ContinueAsNewWorkflow events, which are expected to contain a full SerializedState struct, in contrast to the WorkflowExecutionStartedEvent which contains the initial StateData struct only.

When a WorkflowExecutionStartedEvent is recieved, the workflowEpoch is set to 1, when a ContinueAsNewWorkflow event is recieved, the SerializedState is unmarshalled and the WorkflowEpoch is incremented.

Not totally happy with how this interacts with the error handling mechanism, but error handling needs some cleanup anyhow, so this is good for now.

/cc @bgentry this might break some tests, since it changes the return type of `f.Tick`