Ability to create two or more LTI consumers through the Django admin with an empty instance_guid field.

The "oauth_body_hash" appeared twice in the auth header in the request
when posting grade back to tool consumer. However, the signature sent
from edX is calculated based on only one oauth_body_hash.
On the tool consumer side, the signature is calculated based on the auth
header and will use the duplicated fields. So the signatures will not match.
And request will fail the signature validation.

The bug was introduced in this commit:
https://github.com/edx/edx-platform/commit/03cee389e0869263f5f9977098770495b5216733
on July 12th by updating the oauthlib.

Because 0.7.2(original version) doesn't have oauth_body_hash support, so a custom
OAuth1 client was implemented to add oauth_body_hash to the headers:
https://github.com/edx/edx-platform/blob/f5d0f3ff55d264ed4b68a24808b255aef5d8dad2/lms/djangoapps/lti_provider/outcomes.py#L24.
However, the new oauthlib 1.0.3 has support for oauth_body_hash
(https://github.com/idan/oauthlib/commit/51675237c410b413a11091926436420493c52866#diff-c2a1e5f1ddfe8e48ff62b59eb952644eR180).
So after updating library, oauth_body_hash is added twice.

This fixes the bug by removing the custom client and use the oauthlib
default client to generate the auth header.

Please note that this is a squshed commit and the work of:
Symbolist, macdiesel, nedbat, doctoryes, muzaffaryousaf and muhammad-ammar

This is necessary to properly implement the LTI outcome passback
spec. It was not included previously because it was causing problems
with Canvas, but Blackboard will not accept outcomes unless they are
properly signed.

The requests_oauthlib doesn't support the body hash spec out of the
box, so BodyHashClient needed to be made. Fortunately, it's a pretty
simple spec:

https://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/oauth-bodyhash.html

This change allows graded assignments to be added to a campus LMS
regardless of the granularity at which the problem sits. Previously
a grade could only be returned if the usage ID for the problem itself
was specified in the LTI launch.

The code assumes that courses taking advantage of this functionality
are arranged in a hiearchy (with sections being parents to verticals,
and verticals being parents to problems). When a grading event occurs
it traverses the parent hiearchy to identify any previous graded LTI
launches for which the new scoring event should generate a grade
update. It then calculates and sends scores to each of those outcome
services.

Since grade calculation is an expensive operation, the code optimizes
the case where a problem has been added only once as a leaf unit. In
that case it is able to behave as before, just taking the grade from
the signal without having to calculate grades for the whole course.

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.