Improve decoupling between active object definition and state machine definition

[TSMotter]

• The following is true for all active objects defined in this project as it is today, but let's take the class Toaster, from samples/toaster/main.cpp as a study case here...
• Currently, when you define an active object (like Toaster) it will contain, amongst other things, an instance of a class StateManager
  • This object is the one that will perform state transitions and call the state's process_event methods, based on the events removed from the object's queue
• In order to create a StateManager object, we need to describe the object's Hierarchical State Machines (HSM)
• The HSM is modeled as a "n-ary tree", that presents the hierarchical relationship between the states
• Also, to be able to access the nodes (states), a map is defined as a member of the active object to allow referencing specific nodes via an enumeration:

std::map<StateValue, tree<ToasterSuperState_ptr>::iterator> m_states;
/* ... */
if (m_next_state != m_states[StateValue::UNKNOWN])

• This makes it so that the definition of a new object is really painful, there is so much boiler plate code and coupling
• Just like the class StateManager does not need to know the tree definition, and just acts on the tree nodes in an abstract manner, the class Toaster (used here as an example) ideally would also not need to be responsible for defining the FSM, it could just be inputed to it in it's creation
• I believe that the best approach would be to describe a FSM in it's own independent scope, and when creating an active object, I pass as a parameter that FSM definition