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 pretty sure this never did anything meaningful.

The unique part of this test is that it manually passes in a garbage
`submission_uuid` [1]. As discussed face-to-face, the handler's
docstring _does_ mention this parameter [2], though it's never actually
used or referenced 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/openassessment/xblock/test/test_peer.py#L575
[2] https://github.com/stvstnfrd/edx-ora2/blob/uuid/verify/openassessment/xblock/peer_assessment_mixin.py#L42