Make state change records themselves be entities with bundles

Here's a start on this work. I'll post two patches, one against 7.x-2.x and one against #1412742: Refactor State Flow to be entity type agnostic (Rename state_flow to state_flow_node).

There are still plenty of open questions here like:

What should this entity type be called?
-I'm currently going with state_flow_history_entity. Perhaps it's overly verbose. For now it makes testing a little easier.

What role should bundles play?
-I could see bundles (and therefore fields) changing based on the workflow being used. So the workflow used by Article nodes might need a bunch of fields on it's state flow history entity. These fields could track the next relevant user with a user ref field and checkboxes for whether the Article has been cleared by the Legal and Marketing departments. Blog nodes might only need the Log textarea that is already in State Flow 7.x-1.x. So the node type would determine which workflow is used and the workflow determines which state_flow_history_entity bundle is needed. I think this approach would work fine with what I'm doing in http://drupal.org/sandbox/stevector/1405838

And here's a patch that just shows the changes since #1412742: Refactor State Flow to be entity type agnostic (Rename state_flow to state_flow_node)

I'm attaching a sample feature that this patch makes possible. It attaches a user ref field to the state_flow_history_entity. It also provides a rule that sends an email to the user referenced in the field when the state change occurs.

yeha,

Thanks for reviewing! Currently in that patch there state_flow_history_entity has only one bundle. I think it is an open question how the bundle would vary if there were than one.

In the scenario I describe in #1, state_flow_history_entity bundles would vary on the same conditions as the workflow so if two node types used the same workflow, they would also use the same state_flow_history_entity bundle.

Since none of that code is written, it could work on a different model. Perhaps bundle should be selected completely independent of workflow.

Yes yeha, #7 makes sense.

I would add that the workflow could also also vary based on the values in the state_flow_history_entity itself. A commonly requested use case is "approval checkboxes." An organization may need a blog post to be "marketing approved," and "508 compliant." Those could be checkbox fields on the state_flow_history_entity and the workflow/events/states could prevent the a node from moving to a state like Published until all those boxes are checked.

It would be problematic if the workflow looked for a certain checkbox field but the state_flow_history_entity bundle in use didn't have that field. Of course the UI could give warning messages to protect against that situation and site-builders will always figure out ways to shoot themselves in the foot.

State change records as entities is in 3.x. There is currently no bundle support. Switching back to active.