Verify submission_uuid when creating assessments

This corrects an issue where assessments were sometimes incorrectly
associated with the wrong response.

The behavior was caused because the POST request to the `peer_assess`
handler only contained the feedback text/options and did _not_ include
mention of which original response was being assessed. If the current
workflow item is updated on the server _after_ the page first loads but
_before_ the page is submitted, this submission will be incorrectly
associated with the following response.

Steps to reproduce:
- Submit a response (User A).
- Wait for peers to submit responses (User B and User C).
- Load page with first peer response to be assessed (not not submit).
- Open the same page again in a new tab.
- In 1st tab, assess and submit assessment for User B.
- In 2nd tab, assess and submit assessment for User B.
- Notice that your assessment for User B's response is also applied to
  User C's response.

This changeset does _not_ restore data retroactively.
I'm not sure this never did anything meaningful.

The unique part of this test is that it manually passes in a garbage
submission_uuid [1]. Interestingly, the handler's docstring does mention
this parameter [2], though it's never actually used anywhere.

Now, this test actually does verify the intended behavior when an
invalid UUID is submitted.

[1] https://github.com/stvstnfrd/edx-ora2/blob/uuid/verify-upstream/openassessment/xblock/test/test_peer.py#L564
[2] https://github.com/stvstnfrd/edx-ora2/blob/uuid/verify-upstream/openassessment/xblock/peer_assessment_mixin.py#L42