...will be reimplemented in Proctor xmodule soon.

StudentModule specifies student, course id, and module state key must
all be unique together. The reset code in module_tree_reset was calling
get without specifying course_id which means if two courses (with
different course ids) share the same users and module state keys then
calling StudentModule.objects.get with only the student and module state
key raises an error for users that tried both courses. Specifying all
unique_together fields fixes the issue.

reset_3091_exam_attempts -> reset_attempts
get_submission_history_statistics -> attempt_stats

History tracking enables never selecting the same child twice. Currently
this functionality is tied to the randomize xmodule's use_randrange
attribute.

TODO: Add new xml attribute `no_repeats` to toggle history tracking

Massive code clean-up as well.

Massive code clean-up as well.

The 'index' view still contains baked-in course ids - will fix this
later ideally by getting rid of 'index' and using the instructor API
instead which mostly does the same thing.

cleaner than having periodic_check calling itself in a loop via
setTimeout

* pep8/pyflakes fixes
* removed old code

This completely removes the direct dependency on django and allows these
settings to be configured in the advanced settings pane in Studio and/or
in the course policy.json.

Use self.runtime.get_real_user(self.anonymous_student_id) to fetch the
django User object instead of importing django directly.

xmodule_assets doesn't pass edx's django settings when it executes
resulting in an import error for xmodules that access django settings
directly or imports code that does.

Updated ProctorPanel to move all code that needs to read from django
settings into __init__. This includes the import of
django.contrib.auth.models.User which automatically tries to read from
django settings on load.

Refactored for latest edX changes

(cherry picked from commit cc083275)

(cherry picked from commit faefba91)

The IDDE implementation relied on a StudentModule being created for a
particular block in order to set the extended due date on that block.
Since StudentModules seem to be created on demand whenever data is
written to an attribute with Scope.user_state, it meant that if a
homework problem hadn't yet been touched by a student it was possible
that the due date extension wouldn't take effect for that problem, even
if the due date extension was successfully set for the parent unit.

This patch fixes this problem by creating new StudentModules as
necessary in order to make sure extended due dates propogate properly to
all problems in a unit.

(cherry picked from commit 209c15d1518c7a0df8dd44ff8e0a900cd1c9fdc4)

(cherry picked from commit 9949c3d490408aba8a61259439412d273c5c2a95)

fix for modal appearing off-screen

ORA2 release 2014-05-19

Sarina/051914 language update

SymbolicResponse fix error message.

Online help system