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 know in the past we had issues where student's browsers were manipulating values stored in the DOM, and the submissions UUIDs were not returned properly back to the server. data attributes may be safe enough that this will work.