Stop traversing oneOf and anyOf combiners when filling/removing defaults

[eslavich]

This PR completely disables filling/remove defaults from subschemas within oneOf or anyOf combiners. #809 demonstrates a serious bug in the defaults code that prevents use of oneOf in most realistic cases. Given that there isn't a clear correct answer when choosing a default from among multiple oneOf subschemas, I'm inclined to ignore them when processing defaults.

I also propose that we do away with defaults for anyOf. The way anyOf currently behaves is to always add a default from the first subschema. If the object actually matches one of the subsequent subschemas, then we'll be adding a default from the wrong type!

With these changes, the remaining default rules are as follows, for a given missing property:

• If an object's own property definition has a default, use that
• Otherwise, if there is an allOf combiner, use the first default value available for that property among the combiner's subschemas. The first listed subschema in the allOf array has highest precedence.
• Defaults from any other combiners are ignored

Milestoning this as 2.7.0, since it doesn't seem possible that anyone could be successfully using defaults with these combiners given the bugs.

Resolves #809

[perrygreenfield]

LGTM