WIP: Django Model backed XBlock state storage

![workbench_storage](https://f.cloud.github.com/assets/41625/2304521/14761768-a223-11e3-8ef4-11abd5c2de47.png)

@nedbat, @cpennington: This is functional but not ready for serious review. I'm opening this PR so that I could ask some questions on direction before I cleaned it up.

### Motivation
On edx-tim, we're using workbench to develop an app where part of the state is stored in django-backed apps, and part of the state is in the XBlock. Making edits to the code bounces the server causing XBlock state to be lost. This is painful.

### Approach
I created an XBlockState model so that we could take advantage of Django model admin tools for state introspection. This feature abuses the fact that scenario load order can be made predictable (thank you @nedbat for showing me where to go to ensure that), and that given the same scenarios, the same IDs will be assigned. So all the state that isn't student state is being recreated everytime the server bounces, it just happens that it's being updated with the exact same values. An exception to this are the children entries. Since that's an append-only operation, preserving the children scope entries between server startups would just cause it to grow longer and longer each time. So we kind of cheat and wipe all the children scope entries at startup.

### Limitations
* Performance: Ignored as a consideration. It's good enough for the simple development I'm doing.
* Fragility: If you add a scenario, many IDs will change and it is likely that student state will no longer line up with the appropriate definition/usage IDs, and you'll need to wipe everything. I'm going to make a management command to this effect. The real fix for this would be to make ID generation path/slug based, but that seemed like it might require deeper changes, and my primary motiviation is to unblock edx-tim development for this coming week.

### Questions
1. How should integration work? Should it be specified as a startup option? Config option? Both? Should the default switch to this? Or only after we get stable slug-based IDs for workshop?
2. Is it straightforward to make slug-based IDs?

Thank you.