Feature/brian/regrade celery 2

### Implements the ability to rescore problems in a background task.

#### Instructor Dashboard:

Provides a new section on the grading tab of the instructor dashboard, where staff can specify a problem URL and either rescore all students who have submitted an answer to the problem, or reset attempts to zero for all students who have viewed the problem. A third button permits staff to see a history of all background tasks that have been submitted for the course and problem, rendered as a table at the bottom of the page.

Two new buttons are added to the per-student section of the grading tab. One permits a background task to be started to rescore a specific student's response to a particular problem. The second is to see a history of all background tasks that have been submitted for the course for that particular student and problem.

While on the page, a table appears with the status of any background tasks for the current course that are still running. The tasks that are still unfinished have their status updated every five seconds.

#### Task submission:

A CourseTaskLog database table is maintained to keep long-term track of what background tasks have been run. It also is used to identify which tasks are currently running. When a new task is requested, a new entry is created in the table, and is updated with the task_id once submitted to celery. The table is then updated when queries for task status are made, if a task is discovered to be revoked. 

When tasks are submitted, information needed from the original web request that is needed for tracking and xqueue configuration are pulled out and passed to the queue, so no request needs to be serialized.

#### Running tasks:

A generic task framework to traverse StudentModule objects is implemented, with rescoring and resetting (and deleting) implemented as visitor algorithms. Each individual StudentModule update should be wrapped in its own transaction.  When a task finishes, either with a status of failure (when an exception is encountered) or success, the CourseTaskLog database table is updated.

#### Rescoring:

Rescoring is implemented at the CapaModule and LoncapaProblem levels. It is mostly the same as checking a problem, except that the student's answer is taken from their persisted state rather than a posted request. Also, there is no rendering of html necessary.

Problems that support file submissions, like Code Response problems, do not necessarily store the student's answer in the StudentModule persisted state. And since there is currently no good way to tell if a code response was originally submitted as text or as a file, rescoring of these kinds of problems is not supported. This is somewhat convenient, because then all rescoring can be done by the background task synchronously. It doesn't have to queue up the rescoring requests, and wait around for an answer.

#### Errors:

When staff makes a request, it may result in an immediate error. This shows up as a message rather than a failed task on the table of running tasks.

The following are errors:

* The requested problem URL is not recognized as a real module
* The requested problem URL does not point to a module that supports rescoring (e.g. a video, not a problem)
* The requested problem URL does not point to a problem that supports rescoring (e.g. contains a CodeResponse)

If the request does not result in an error, it should show up in the table of running tasks. The last column indicates progress, including the number of attempts, number completed, and the total number of students' responses considered.

The following condition results in a particular student's response not being rescored.  It is counted in the number of students' responses that were attempted, but not in the number that were completed:

* The response was ill-formed in the first place. (E.g. a string when a number is required.)