Changed over to a scheme that allows us to write code that's run when fields change that does NOT require database persistence

@blardo @bentleycook

This is your brain....
![depositphotos_7277609_xs](https://f.cloud.github.com/assets/1839452/1414624/5491debc-3e97-11e3-8e33-3ede82e72c2c.jpg)


This is your brain when you try to test old code...
![flickr_-_cyclonebill_-_spejlg](https://f.cloud.github.com/assets/1839452/1414626/69bd9326-3e97-11e3-88a2-c38863294fd9.jpg)


I've tagged you guys on this pull request because I decided to try a new approach with the django ondelta pattern that we wanted to use. This approach requires no database hits, which means you don't have to worry about pickling / unpickling concerns like before (or json serialization problems like we were having before that). All this does is make a deep copy of the model's 'snapshot' and check for differences on save. This approach is inspired by http://stackoverflow.com/questions/110803/dirty-fields-in-django. This approach makes sure that we only notify of changes when save is called and if save is called multiple times the snapshot is kept up to date. I've included a test suite, there aren't may tests but really, this Mixin doesn't DO much now, and the assertions that are made in the unit tests (hey, when I made changes did you get called the appropriate number of times in the appropriate order? Are pretty helpful in ensuring behavior.

  1. Do you guys like this approach?
  2. Can you suggest more tests that would help us ensure that this behaves the way we want? Specifically I'm looking for negative test cases.

If it's not obvious the mainline is the old way that includes persistence and the feature/no-persistence branch is the new approach I'm trying. I really appreciate your guys' thoughts I really need an outside opinion here.