Implement Track Changes

@stephensanchez please. I'll be on vacation next week, but @caesar2164 and @stvstnfrd will be around and can handle our end of the PR process.

* Creates "TrackChanges" django model, which ties a (submission_uuid,
  scorer_id) pair to a set of edits suggested by peers for a particular
  submission.
* Adds machinery for on-the-fly installation of the New York Times's ICE
  library for collaborative editing, allowing peer assessors to create
  marked-up versions of submissions, which can then be returned to the
  author as feedback.
* Adds machinery for displaying suggested edits to the creator of a
  submission with their scores and other feedback.
* Configurable within Studio on a per-Assessment basis by including a
  URL to the ICE library as part of the assessment definition.
* For additional details, see:
  https://docs.google.com/document/d/18PITJu133sFpDl_B2GCbo2eb0GODcwVmVsktwPQfVSg/edit?usp=sharing

Co-authored-by: Giulio Gratta <giulio@giuliogratta.com>
Co-authored-by: Steven Burch <stv@stanford.edu>
Co-authored-by: Joe Blaylock <jrbl@jrbl.org>
I would like there to be a track changes API file for this work, that is responsible for all CRUD operations and business logic to the track changes model. This would keep any track changes logic from existing in the peer assessment API, and would avoid model queries in the XBlock mixin (grade_mixin.py, I'll add a comment there) 

Theoretically, you could create a context manager for track_changes that could be used in the peer assessment mixin (or eventually, other mixins) that can:
1) check if track_changes is enabled, 
2) invoke the peer assessment call, 
3) create the TrackChanges model associated, 
4) wrap all of this in a single DB transaction.

Also, this will make the simple interactions with creating and reading TrackChanges operations easily testable separate from the APIs and mixins.