RFC: statemachine.State as an interface instead of a struct

[schmichael]

Pros to an interface

• Users can tuck extra metadata into their implementation
• Manually creating State structs smells funny

Cons to an interface

• Allows "clever" implementations of methods that should just be getters for immutable values
• Suggests/forces custom implementations which is extra work for users
• Custom implementations mean Yet Another Place to Hide State.

Since #133 just merged I'd rather see how far the Task interface gets us than rush and interface-ify everything and create useless complexity.

[schmichael]

Welp, already found an example of where tucking extra metadata into the State would be helpful. Our internal State model is persisted with Created and Modified timestamps. Modified is easy: you just overwrite it with time.Now() every time.

Created however is a piece of State-specific metadata that needs to be roundtripped from StateStore.Load through the statemachine and back to StateStore.Store. Since statemachine.State is a struct, there's nowhere to put that metadata.

There are 2 ways to mitigate this:

1. Add a StateCreated field to our custom Task implementation and hide the extra metadata there since Task is passed through the statemachine to Load and Store. Yuck! Gross encapsulation/isolation violation.
2. Simply set the State's Created timestamp to the Task's Created timestamp. Not ideal, but honestly the difference between the two would only represent some implementation specific latency number that's best measured other ways.

Going with 2 for now... may still end up switching State to an interface though.