Field Overrides

Architecture for arbitrary field overrides, field overrides for
individual students, and a reimplementation of the individual due date
feature.

This work introduces an architecture, used with the 'authored_data'
portion of LmsFieldData, which allows arbitrary field overrides to be
made for fields that are part of the course content or settings (Mongo
data).  The basic architecture is extensible by means of writing and
configuring arbitrary field override providers.

One concrete implementation of a field override provider is provided
which allows for overrides to be for individual students.  This provider
is then used as a basis for reimplementing the individual due date
extensions feature as a proof of concept for the design.

One can imagine writing override providers that provide overrides based
on a student's membership in a cohort or other similar idea.  This work
is being done, in fact, to pave the way for the Personal Online Courses
feature being developed by MIT, which will use an override provider very
much long those lines.
Looks like "heritable" and "inheritable" are reasonable synonyms. I would err on the side of using the more commonly understood term ("inheritable") to improve code readability. "Heritable" sounds odd to me - I ran this by the docs team, and they agree (""heritable" sounds odd to me.  for code doc, saying x "herits" from y would be weird", "inheritable is preferred for most everything except legalese", "I'd avoid "heritable" unless it's absolutely necessary for some technical reason" from 3/4 doc teams members)