First cut at tight error handling.

When an error occurs, we collect the details, and then self-signal the workflow with the error details.

TODO: FSM should notice error event markers and use the ErrorHandler appropriately, perhaps transitioning to a (canned?) error *FSMState that knows how to
deal with the signal
serialize event ids, not the full event in Error States,  add the concept of an ErrorState and a default impl to FSM
update Tick to use the FSM errorState to process any error events and give us a good state and data to use when errors have occurred
wire in error handling to Tick
cleanup
start the poller synchronously in fsm start
doc
add vars for DecisionTypes and EventTypes that contain all the valid values
helper maps and String() methods for HistoryEvent and *Decision
initial test for error handling mechanism, fix to bugs the test found
allow turning off panicRecovery in fsm, to make testing error handling easier
if allowPanics then panic on errors, rather than signaling an error to the workflow
Merge pull request #6 from sclasen/error-handling

First cut at tight error handling.