Add an example script
Make State handle conditions on different objects

Now DbcUseCases and Planners can have multiple postconditions and goals
on different objects. `State#satisfy?` will check if *all* the
conditions are satisfied, effectively ANDing them. In other words, State
does not support, for the time being, conditions of the form
`object1.attr == val1 || object2.attr == val2`
Merge branch 'multiple-postconditions' into examples
Modify example to use new form of postconditions
Add another example script

This example uncovered a flaw with the way DbcMethods parameters are
handled that has to do with the closure nature of Ruby blocks.
Implement breadth-first forward state-search
Rename the recursive forward search method

The new name reflects the depth-first nature of the method better,
especially given that the planner now also has a breadth-first search
method.
Correct an implementation error of the BFS algorithm

In breadth-first search, declaring failure when the planner cannot find
any applicable methods to the current (non-goal) state is wrong because
there cloud be other states in the queue waiting to be checked.
Basically, this current state is a leaf node, and instead of declaring
failure, the planner should move on and check the next state in the
queue (if any).
Set the default planning algorithm to BFS

Breadth-first forward-search is currently the best implemented planning
algorithm as it returns the shortest sequence diagrams, which match the
manually-generated ones.
Implement a (DbC methods) noise generator

Noise is basically a bunch of DbC methods that are always applicable and
that do nothing. Such methods will be used to investigate the effect of
additional methods that does not contribute to solving the planning
problem at hand on the planner.
Start solving the problem of DbcMethod parameters

Due to the closure nature of Ruby blocks, if a DbcMethod's
pre/postcondition refers to a (DbcObject) parameter, it will always
refer to the object defined where the condition block itself is defined,
never its clones that are generated and modified during (deterministic)
planning. The solution is to get hold of the needed parameter by making
the DbcObject ask its state to get it a DbcObject of the required DbC
class.

Currently, the solution will not work in all cases because there is a
problem in cloning DbcObjects: Because of the current recursive
implementation of `DbcObject#clone`, `State#clone` will create multiple
separate clones of the same DbcObject if it is referred to by multiple
DbcObjects.
Demonstrate the "over-cloning" problem by a test
Use new way of referring to DbcMethod parameters

As part of the change, and as advised by Dr. Ahmed, I've made instance
variables (and in effect, parameters) more abstract by replacing
specific values (such as location) with boolean flags (such as
`is_final_meeting_time_set`).
Merge branch 'examples' into overcloning
Solve the problem of over-cloning

Now, DbcObjects do not deep-copy their instance variables that are
themselves DbcObjects. Instead, State is responsible for copying
DbcObjects that were not cloned and for updating referencing correctly.
Change a precondition to the desired correct one
Use the default planning algorithm

The current default algorithm is breadth-first forward-search, which is
the best (in terms of the length of generated sequence diagrams)
planning algorithm implemented so far.
Keep track of number of states tested for goals

Initially, I called it the number of explored states, but its current
name is more accurate across the different planning algorithms.
Leave the plan instance variable uninitialized

An empty array corresponds to the empty plan, which is actually the
solution when the initial state is a goal state.
Remove duplicated tests