Tests for a new schema validation method which returns multiple errors

As a step towards giving the client more information about schema errors
we need to return all errors, not just the first. They can then fix all
the errors at once and resend the data/re upload.
Working code for returning all schema validation errors

Draft4 is the latest schema spec.

We will only return the message for now. On a future iteration we may
want to construct more detailed errors from the Exception attributes
other than message the json schema library provides.
Integration type test of dataset store - excercises multiple error paths

fixes other tests for this new pattern.

These errors may later become dicts with a location attribute.
This will specify the problematic part of the data.

These errors will be dumped to json and returned to the client as a list
of strings for now
Refactor store to return errors if problems and skip store.

Returns empty list if no problems.

Operations of data which validate or change records will return lists of
tuples
Tests for auto id stuff handling tuple response
Code and doctest fixes for returning tuples

Also slightly better error messages

Tests data set store tests should now pass.
Add mock handling store and returning errors to write integration tests

Should now be ready to refactor write to handle the new response from
store

This also expects incorrect headers to return an list of one errors.
This should help us handle things consistently. It begs the question
though. Should empty and create also return lists of errors? - will
entail more changes than just backdrop and pp-admin.
Refactor write to handle error list rather than validationerror

Still catch no data exception separately

Also returns error list for incorrect headers
pep 8 suggested fix

This reads slightly more clearly.
Handle multiple messages to prepare for tim suggested change

we will now use jsonify with multiple messages.

Is this right? and what's the deal with response data having a status?
Change response to be jsonify to prevent weird escaping

does 'messages' confuse things though? Should this be consistent in
other responses? or only 400s?

need to fix get_json_from_request?
Test that we do no store data or add period keys if errors

Also fix the tests - without the is_ they behave VERY STRANGELY and
don't all fail when they should (and don't complain about it).
Improve the clarity of the logic to return early if errors
Merge pull request #347 from alphagov/consistent-write-errors-refactor

Consistent write errors refactor