This change is a follow-up to the chages in PR 8347, which removed the
edX login page from the workflow for a new user. Where previously we
redirected a user to the login page, PR 8347 instead creates a new user
transparently and logs them in.

The initial reason for splitting the LTI view between lti_launch and
lti_run was so that there was a target for the GET request that
followed the login page. Since we no longer use the login page, we
no longer need the second view. We also don't need to store the LTI
parameters in the session any more, since they are not persisting
between calls. This simplifies the view logic significantly.

The other change here is to fetch the LtiConsumer object early in
the view, and pass it to the SignatureValidator and scoring system.
When the views were split, this required multiple DB hits for the
same data; we're now only fetching it once.

This change allows the LTI provider to pass grades back to the campus LMS platform using the
LTI outcome service. For full details of the outcome service, see:
    http://www.imsglobal.org/LTI/v1p1/ltiIMGv1p1.html

In brief, the LTI 1.1 spec defines an outcome service that can be offered by an LTI consumer.
The consumer determines whether a score should be returned (in Canvas, this means that the LTI
tool is used in an assignment, and the launch was performed by a student). If so, it sends
two additional parameters along with the LTI launch:

lis_outcome_service_url: the endpoint for the outcome service on the consumer;
lis_result_sourcedid: a unique identifier for the row in the gradebook (i.e. the tool/student/assignment combination).

The LTI Provider launch view detects the presence of these optional fields, and creates database
records for the specific Outcome Service and for the graded LTI launch. Later, when a score on
edX changes (identified using the signal mechanism from previous LTI Provider pull requests),
a Celery task is launched to pass the score back to the LTI consumer.