Organizing the integration tests
First test of grammar, no data

Inserting cassert in header test, it can be useful. My first
version of empty_grammar test was using assert to identify problem,
but I changed as a exercise of not use assert. Weird, huh. -.-'
Add no more is a pure abstract function

Add no more is a pure abstract function. Now it is a normal function
that need be overloaded.
Putting some log on symbol
Removing mock classes: Belief and Functor
Removing Plan mocked class
Adding class EventType to be used by a plan
Adding TriggerEvent to be used by the Plan class
Forgotten the *_op destructor
Type value of Symbol comes from a enum

Changing to make the type value of Symbol class that was hard-coded
to comes from a enum. I could have changed the type of the type field
to depend on this new enum, but I prefer not do it because it will
prevent some extensions from the user side. What I mean by that? Lets
say that I'd like to make a T class and extend Symbol too. I can
put a value type that the system is not using right now. If I change
the type, the user will need change the enum. So, it is just to prevent
people that need to do patches to have to do it again because some
weird conflict...
Implementing Parameter and StackedSymbol class

I did Parameter extend StackedSymbol class because I need a way to
force the interface of what can be more than one element. I'm worried
that it will conflict with the add method in Symbol class. -.-'
Well the future test case will be util to see it, I hope.
Array set and meta notes

This class represents a array element and, also, a meta note of a
element. For example, a element declared as `a.' in reality can
be something like this `a[source(file.asl)].'. I'll not worried about
it right now.
Action class represents a set of actions

A plan is a tuple of head, context and action. A action is a set of
one or more actions that need by done to a plan be done.