Invalid resolution of nested oneOf for schemas of differing types

[fmigneault]

Describe the bug

When nested oneOf are used with types that do not match, the resolution fails.
This is somewhat related to #214, but contrary to the oneOf using two distinct object references in:
https://github.com/cwacek/python-jsonschema-objects/blob/master/test/test_regression_214.py#L28-L33

... the nested oneOf also uses different types (as the parent one does in https://github.com/cwacek/python-jsonschema-objects/blob/master/test/test_regression_214.py#L17-L21).

Example Schema and code

I reused the existing test with slight modifications to demonstrate the issue.
master...fmigneault:python-jsonschema-objects:nested-oneOf-regression-example

Expected behavior

As demonstrated with jsonschema.validate (master...fmigneault:python-jsonschema-objects:nested-oneOf-regression-example#diff-8af35489f471b9a4a568c247e1bc375c74c9d577e540975ef8fab8d5feae8575R81), the schema is valid.
It is expected that each combination of

    obj1 = ns.MainObject(**{"location": 2})  # FAIL!
    obj2 = ns.MainObject(**{"location": {"type": "Location2"}})
    obj3 = ns.MainObject(**{"location": "unique:12"})

Would resolve to the appropriate type/schema without error.

A quick workaround that lets the resolution succeed is to move the Location1 (number) reference under the parent oneOf. In this case, it resolves correctly (just like UNIQUE_STRING did). However, because of specific schema definitions and references used elsewhere in by actual schema, it cannot be moved like so, and must remain in the nested oneOf.

[fmigneault]

@cwacek Thanks for the new release! 🚀