Unify initialization of TaskTypes and ScoreTypes

Simplify get_{task,score}_type by making them accept as parameters,
respectively, task_type_name and task_type_parameters for TaskTypes and
score_type_name, score_type_parameters and public_testcases for
ScoreTypes. Alternatively one can give a dataset, that already contains
all this information as attributes.

Also provide separate functions, get_{task,score}_type_class, to get
only the {Task,Score}Type class given its name.

This means that the constructor of TaskType won't get the Job and the
FileCacher. Parameters can therefore be easily stored and accessed in
TaskType.parameters, whereas Job and FileCacher will be given as
parameters in the call to .compile() and .evaluate(). They'll be local
variables and not object attributes. This way a single TaskType instance
can be used on more than one Job.

Also note that:
- task_type_parameters will be JSON-decoded inside get_task_type, and
  not inside methods of Job.
- create_sandbox doesn't need to have access to the full TaskType but
  only to the FileCacher
Reorder class definitions in cms.db.Task

Put them in the order they come into play in the contest execution:
Statement, Attachment, SubmissionFormatElement, Dataset, Manager,
Testcase.

Also reorder some fields inside Testcase: put dataset_id and dataset at
the beginning and not at the end.
Identify Testcases with a string codename [1/3]

Rather than by an integer index.

Also bind each Evaluation to its Testcase using a foreign key and a
relationship, instead of relying on them having the same codename. This
way Evaluations will be deleted when their Testcase is, and there's no
risk that their names go "out of sync".
Identify Testcases with a string codename [2/3]

Mostly straightforward changes. Job.testcases and Job.evaluations are
now indexed by strings and not by integers (makes it also easier to
convert to and from JSON); the same holds for the public_testcases
argument for ScoreTypes; TaskType.evaluate_testcase also receives a
string. When EvaluationService creates an Evaluation it cannot pass the
codename to the constructor but has to use it to get the Testcase from
the Dataset.

When ScoreTypes need to put an order on Testcase (to group them into
subtasks or to present them in the graphical output) they use the
lexicographical order of the codenames.
Identify Testcases with a string codename [3/3]

Mostly straightforward again. Use the ID of the Testcase instead of its
codename ("namespaced" with the ID of the Dataset) as HTML form input
names (and hence HTTP query argument names) as it doesn't need to be
escaped and pose no risk. Given the new sorting criteria for Evaluations
in ScoreTypes, to preserve the current behavior import Testcases with
their numerical indexed (zero-padded to three digits) as codename.
Use JobGroup

Instead of combining the evaluations for all testcases into a single
EvaluationJob, use one for each testcase and introduce a JobGroup to
"bind" them all together.

We needed to remove the testcases and evaluations attributes from
EvaluationJob and add input, output and all the other fields that
TaskTypes dynamically put in the elements inserted in evaluations:
success, outcome, text, user_output, plus (user_output was called
output before but has been renamed to avoid collision).

JobGroup contains a dict of Jobs and a success attribute, which is
basically the AND of the success of all the Jobs it contains. The
methods to create Jobs from Submissions and UserTests have been moved
here too, with slight modifications (usually just the last two lines of
code, with the exception of from_submission_evaluation which required
some more changes).

The loop that breaks a JobGroup into single Jobs (the one that was in
TaskType.evaluate and called .evaluate_testcase) has been moved into
Worker. Therefore TaskType.evaluate has been removed and
.evaluate_testcase has been renamed to .evaluate. Worker, on the other
hand, doesn't need store the TaskType as class-level attribute just to
set its ignore_job attribute: it's now storing ignore_job itself (the
session attribute has also been removed as it was completely unused).
Move some code from ES to Job

Add to_{submission,user_test}_{compilation,evaluation} to hold code
involved in the converstion between DB model and Job structures.

Also set a couple of user test related attributes of EvaluationJob
inside from_user_test_evaluation.
Other innocent fixes
Avoid TaskType.evaluate() return its success

Just store it in Job.success, as .compile() does (we were actually
already doing it).
Fix a couple of damn small bugs
Store execution_wall_clock_time for UserTestResults