update permutation algorithms to return the most recent checkpoint when generating crash states

[ashmrtn]

Part of the revised version of #12.

Checkpoints require support across many parts of CrashMonkey. This part slightly modifies how crash states are generated so that we can give user consistency tests more information about the crash state they are working with.

For checkpoints, we can assume 2 things:

1. the user has just performed a sync/fsync request of some form
2. this call will block until all parts of the checkpoint are completed

When a new crash state is generated, the Permuter (or subclass) that generated the crash state should inform the CrashMonkey test harness of the most recent checkpoint passed in the bio sequence. An example of a workload, generated crash state, and checkpoint number are shown below.

workload:
+-------------+-------------+-------------+-------------+-------------+
|   epoch 1   |   epoch 2   | checkpoint  |   epoch 3   |   epoch 4   |
+-------------+-------------+-------------+-------------+-------------+

generated crash state:
+-------------+-------------+-------------+-----------------+
|   epoch 1   |   epoch 2   | checkpoint  | partial epoch 3 |
+-------------+-------------+-------------+-----------------+

returned checkpoint value: 1

Another example could be:

workload:
+-------------+-------------+-------------+-------------+-------------+
|   epoch 1   |   epoch 2   | checkpoint  |   epoch 3   |   epoch 4   |
+-------------+-------------+-------------+-------------+-------------+

generated crash state:
+-------------+-----------------+
|   epoch 1   | partial epoch 2 |
+-------------+-----------------+

returned checkpoint value: 0