Added state transition limitations

[AlexmReynolds]

Added allowedStates array to state object so we can limit which state can transition to another state. This creates a more tightly coupled state machine.

Updated tests to reflect new feature.

Updated Readme to reflect changes

[ifandelse]

@AlexmReynolds @pajtai - guys first of all I wanted to say that I really appreciate the thought you've put into this. I definitely get what you're doing. I'd like to throw a gist or two together as an alternative and get your feedback, since I'm hesitant to put things that are too prescriptive in machina core. (Prescriptive isn't bad at all, but the goal is for machina to be the initial utility belt, and the ability to extend into customized constructors is the extension point for this kind of behavior.) I'll throw some gists together tonight and put the links here for you to check out. I've been pondering a machina.contrib project that would be showcase/collection of customized (yet base) fsm constructors and think this kind of thing would fit well into that. More in a bit....

[ifandelse]

@AlexmReynolds, @pajtai & @dcneiner
Ok - here's one possibility: https://gist.github.com/ifandelse/31e9924e5b75d3d3d6c0.

It might be helpful to read over this conversation between me and @burin - it will give you an idea of how I've used constraints to prevent a transition before it should happen. So it's not just that you might have a list of allowable states to which you can transition, but also constraints that dictate if a valid transition can actually happen yet or not. I'm not saying that the gist above is the best idea - I'm sure it could be better. But I'm very careful about what makes it into machina core, since I don't want to prevent the very kind of innovations were discussing in derived FSM constructors.

[eliperelman]

I'd like to move to close this PR. It adds an unnecessary dependency on jQuery for deferreds which can abstracted in userland code, not baked into the core. The jQuery dependency would most likely make machina not as relevant for Node.js usage.

[ifandelse]

@AlexmReynolds, @pajtai & @dcneiner - I agree with @eliperelman in that I don't want to add a jQuery dependency. At the moment I'm quite torn about whether or not I will include a promise-based API in the future (leaning in the "no" direction). It comes down to that I feel FSMs are best modeled in a more reactive-style way. The tough part about this is that I think the ideas you guys have are very interesting. What I'd recommend is trying to look into ways to "plug in" functionality in a contrib project. If things that live in contrib make sense to move into core, then I can come up with a flow to help make that happen. There's not a formal plugin mechanism for machina - one may emerge if necessary, otherwise it can be a matter of patching the FSM prototype, or creating a factory that patches instances as they are created (there's a top level machina namespace event for new FSMs which you can hook into, etc.).

Anyways - I really appreciate the interest and contribution here!