`oneOf` and `anyOf` errors where default values are present

Using `anyOf` or `oneOf` shouldn’t fill JSON object with defaults of non-matching subschemas.

Prior to this change, a JSON object validating against `anyOf` or `oneOf` would be mutated by each subschema with default values, even if that subschema then failed validation. These new properties would then be present in the JSON for validation against subsequent subschemas.

This pull request makes changes so that:

**On Success**
For `anyOf`, the defaults of the first matching subschema persist after returning from the call to `validate`.
For `oneOf`, the defaults of the only matching subschema persist after returning from the call to `validate`.

(It's not obvious what should happen for `allOf`. So we have not attempted to change behaviour here.)

**On Failure**
We set the JSON data back to the original data.


In `test_default_with_strict_and_anyof`, "view" will not be added, because that subschema does not match the data. In `test_default_with_anyof`, because we pass empty data, the default ("view") gets added, which then means the first subschema validates, and the returned data will contain "view".

The data will only ever contain the defaults for the subschema that first passes validation. The looping search stops at this point and returns early, so it seems like a sane approach to me. But as far as I can tell the spec is silent on all these issues.

If you have specific test cases you think I should cover just let me know.

I can't even think of a sensible approach for `allOf`. I suspect it hasn't been fully considered. I think I'm personally going to stop using defaults at all in schemas I write.