Brodie Gaslam

Starting to lean towards the just allowing options and recording them. We could also separately record just the unitizer options as an object, which wouldn't allow a test to modify...

The other issue floating around is the setting of `warn=1` and `error=NULL`. We're very much relying on this everywhere (for an example, see #108)

Another option to deal with: `getOption("crayon.enabled")`.

This is going to be real low priority. Right now one possible approach is to make two copies of the underlying `data.rds` file, and two copies of the test file,...

Possible implementation would be to compute hash and store those so we don't have to store the entire object, but can still tell when the objects are not the same...

Was this not addressed in `mergeStates`? See also #197. Leaving open until we confirm.

So, `mergeStates` just handles the compressed version of state that is kept with the `unitizer` objects for display purposes in diffs. What we're talking about here is the actual state...

Definitely, but this is going to break all the output driven tests so we're going to push this off and combine it with other output breaking tests...

Another thought here was to have a right aligned post-prompt that tells you what happened: ``` unitizer> Y [Y: test added to store] > next_test() [1] TRUE unitizer> ```