Model refactor

[jonathan-j-lee]

• Removed the GeneralSetting model, which contained translations for templates (this will now be handled by Django's built-in translation system, per #45)
  • This takes care of issue #6
• Removed the seemingly unused Progression model
• Removed the FlaggedComment model, which is otherwise identical to the Comment model
  • Comment now has a flagged field
• Used abstract model inheritance to reuse design patterns
• Consolidated the User, UserProgression, and UserData models into the Respondent model
  • Some fields of UserProgression can be inferred from the existence of other models (e.g. the existence of at least one QuantitativeQuestionRating model implies the user made it to the rating stage)
  • This takes care of #26
• Removed redundant state (e.g. average_score, number_ratings in the Comment model)
  • These fields are now computed at runtime using Python's property decorator
• Added uniqueness constraints to ratings (that is, a user should only be able to rate a question or a comment once)
• Overrode __unicode__ for each concrete model to display usable information
• Wrote a custom database migration to restructure the database to comply with models.py
• Documented the new models
• Added unit tests of user feedback storage
• Fixed style issues in models.py
• Added pylint with the pylint_django plugin to the build configuration (#36)

[JustinMi]

also a friendly reminder that after this pull request is merged, we should all git pull origin master and run a migration: python manage.py makemigrations and python manage.py migrate since the models have changed

[jonathan-j-lee]

@JustinMi python manage.py makemigrations essentially looks at the diff between the current database layout (as provided by all the migration files so far) and the layout proposed in models.py, and generates another migration file with some educated guesses for how to restructure the data. python manage.py migrate then applies the operations in this file. However, I manually wrote 0049_model_refactor.py, so there's no need to use makemigrations.

Since this pull request and #48 were developed concurrently, both have migration numbers 49, so whichever is merged later will need to be renumbered to 50.

[liboan]

Didn't notice any issues with data integrity when I looked but worth getting some more eyes on it

[sequoiatree]

I checked too, it gets my badger of approval :3

[sequoiatree]

Woo!