ORA-61: Answer too long error message

[ORA-61](https://openedx.atlassian.net/browse/ORA-61)

It turns out that we were restricting *character* length on the client side (using the textarea's `maxlength` attribute), but checking JSON-encoded *byte* length on the server side (in the submissions API).  Depending on which characters were being encoded, a user could exceed the byte length limit without exceeding the character limit (for example, double-escaped newline chars, non-ASCII unicode, and JSON keys).

This PR addresses the issue in two ways:

1) It suppresses the "field errors" returned by the submissions API, which (a) weren't localized and (b) were a scary `repr` or a dictionary, which users should never have to see.

2) It intercepts "answer too long" request errors from the submissions API and displays the more specific error message: "Your answer is too long."  This is somewhat vague (it doesn't tell the user *how* long), but I think it's clearer than saying something more specific like "JSON encoded byte length > 100K", which the user doesn't have any control over.

There's a related PR in edx-submissions: https://github.com/edx/edx-submissions/pull/7
Once that is reviewed, merged, and released, I'll update the requirements to point to the new version in PyPi.

@srpearce Please review the messaging changes (all in `SUBMIT_ERRORS` on line 29 of `submission_mixin.py`)

@stephensanchez and @gradyward please review the code changes.
Not without some pretty significant changes to how we're doing validation in the submissions API.  We put the answer size check in Django rest framework serializers, and we rely on the serializers to tell us if a submission is valid.  If not, we raise a request error.

I'd also be worried about breaking backwards compatibility by introducing a new exception type, which other clients of the API might not be catching.