This introduces a few features:
* INFO level logging on common events like creating or fetching
  submissions and assessments.
* Parallel event logging for the same.
* Creates a local logs/ directory for development.

For the most part, we rely on XBlock's publish() mechanism to emit
event data. However, because scoring is done at the API layer in a way
that is not directly visible to the OpenAssesmentBlock, we're logging
that event separately with a hacky solution that dynamically loads an
emit function based on a configuration value. This is a stopgap
measure until we can start using the edX analytics API (which is still
in testing).

TIM-260, TIM-378

The autodiscovery used by admin will interact badly with Django
Debug Toolbar's own auto-setup. So we have to be more explicit about
everything and add some settings manually. See:

http://django-debug-toolbar.readthedocs.org/en/1.0/installation.html#explicit-setup

One of many small pull requests that are going to come for [TIM-279].

Requires installation of Chrome extension:
https://chrome.google.com/webstore/detail/django-debug-panel/nbiajhhibgfgkjegbnflpdccejocmbbn

* Improved error handling and reporting

* remaining items:
 - replace submission fk w/ m2m on peerworkflowitem
 - complete move
 - initialize feedback box, grayed out
 - tests

* TODO: incomplete move, usage still in submissions api

Includes a number of JS changes, templates, and handlers to call the workflow api instead of complex, hard-coded logic.

Wiring all the peer queue into place

Updating based on rebase to fix tests

Implement self assessment api

[TIM-202]

Deprecate scenario parser in favor of XML serializer for studio
Clean up validation logic for assessments and add tests.
Add missing test cases for XML serialization/deserialization
Increase browser timeout for Karma (prevent failure in Travis)
Erase coverage between test runs (more accurate reporting)

* Basic parsing of XML rubric's in @ormsbee's proposed format
* Rubrics displayed to user after they've made at least one submission
* Multiple rubrics on the workbench with different evaluation criteria

* Implement a basic XBlock for composing. Allows the user to enter text
  and see what they entered.
* Dirty shell script to install the XBlock demos into this working tree
  so that we can use the workbench for early prototyping. This should
  not be used any more once we integrate into LMS, obviously.

We're not aiming to have an REST API in the MVP. Can re-add when
we get around to implementing it.