Improve some tests' names
Streamline and rename some DbcMethod tests

Since the pre/postcondition attribute is accessible, it can be assigned
an instance of any class. So, there is no real gain of assigning it a
lambda then calling that lambda in the test.
Modify tests to emphasize that State holds objects
Make Planner take DbcClasses instead of DbcMethods

To move from the planning domain to that of software engineering and
object orientation, planners should stop dealing with disembodied
actions and start dealing with DbC methods through their respective
(DbC) classes. This change is a step in that direction.
Refer to methods instead of actions inside Planner
Simplify the structure of the test subdirectory

There wasn't much benefit from organizing test cases hierarchically in
test suites.
Move global test configuration to a separate file
Remove plan accessor since it's being redefined
"Objectify" the plan's string representation

The new representation is better suited for sequence diagrams: instead
of just listing the method names, this new representation contains the
receiver and the parameters, if any, of each method. So, instead of just
`"method"`, the new representation will contain `"object.method(param_1,
..., param_n)"`.

For the time being, the name of the receiver is computed by downcasing
the name of the class to which the method belongs.
Add a Rake task for running the entire test suite

This Rakefile is mostly stolen from Gregory Brown's Ruby Best Practices.
Start implementing a DbC object class
Add receiver_name attribute to DbcMethod

Similar to a regular Ruby method object, a DbC method should know its
receiver (or at least its name). As part of the move towards
state-as-a-set-of-objects, this addition should make tasks like creating
a plan's "objectified" string representation easier.
Make DbC objects know about their DbC methods

As DbC objects are replacing DbC classes at the heart of State, I don't
want--for now at least--the additional complexity of having the
responsibility of instance variables in one class (DbcObject) and the
responsibility of methods in another (DbcClass).
Make State a set of objects

This was a major change that broke Planner, so I changed it accordingly
(except for using use cases to set up the initial state). Planner does
not deal with DbC classes anymore as it doesn't need them: objects
knowing their methods and the names of their classes is sufficient at
the current stage.
Dynamically define accessors for DbC objects

An accessor is defined for each DbC instance variable. These accessors
should come in handy when an instance variable is another DbC object as
the accessor will enable conditions to reference the instance variables
of that object.

These accessors must be defined as singleton methods because otherwise,
different instances of DbcObject representing different instances of
different DbC classes will share the same accessors.
Enable DbC Objects to recursively reset themselves

Resetting is needed because, currently, planners modify the objects
themselves. Recursive reseting is needed because a DbC Object may have
other DbC Objects as instance variables.
Make adding multiple DbC Objects more convenient
Make adding multiple DbC Methods more convenient
Change UseCase to fit in the new picture of State

Use Cases can now hold on to DbC Objects, which shall be used to set up
the initial state of Planners.
Reuse UseCases to set up initial state of Planners