Ports changes to models and model tests along with some settings changes...

... from feature/tracks_activation
I'm perhaps a little late to the party on this, but the CourseSettings model in it's current state seems more like a Proxy model (one that isn't save to the db) than a real db table.  If tracks had a `finalized` or `state` field associated with them (assuming that's the right place to put it) then a proxy model could finalize all tracks associated with the course as well as check if a track is finalized when asked as opposed to saving that information in the db.  I suppose that if you have more fields that can't be derived then having a db model makes sense.