Fsm stack

Added some classes for grouping and stacking FSMs. Closes #73 since it contains all the same additions.

I think the FSMs themselves should remain as bare to bones as possible, in that they contain a state and manage state transitions. Having an FSM sometimes call the exit function and not other times when the state changes makes things unnecessarily complicated for everyone involved.

So I suggest that instead of stacking states we stack FSMs themselves.

It loosely goes something like this: http://imgur.com/29nhK3h

The manager contains, keeps track of and spawns  new stacks when called to. The manager updates every stack each loop. 

Stacks are essentially a group of FSMs. It has two modes of update: update the first in stack or all FSMs in stack. (Later on you might add other update modes, such as updating FSMs in turns or similar)

From the state's point of view, it looks and sees that the FSM has a new variable `stack` which is either null or contains the stack the FSM belongs to. Using this it can either add or remove FSMs to and from the stack.

From the stack the state can access the manager (if not null). Here it can create entirely new stacks for remove them. You can spawn a "Poisoned" state that doesn't interfere with your "Movement" state in any way since they both operate independently from each other.

(Although you can do this with stacks as well when it acts as a list of FSMs: just push the FSM in and take it out when it's run its course)

The nice thing about this system is that you can use any part of it by themselves. You can have FSM with States, a Stack of FSMs with States, or the entire Manager chain depending on how complex a state-flow you require. There's always some overhead the bigger the structure. If this makes any sense.