feat(core): infer $class when obvious

[mttrbrts]

Closes #542

This change allows us to validate and deserialize JSON objects where the root type is known, but where no $class properties for nested objects are provided. This will work for basic cases where there is only one possible concrete subtype.

For example, an object such as this will validate provided that we tell the validator what the root type is.

{
    "$class" : "test.Vehicle",
    "color": "red",
    "wheels" : [{
        "brand" : "Michelin"
    }],
    "owner": {
        "email": "[email protected]"
    }
}

Author Checklist

• Ensure you provide a DCO sign-off for your commits using the --signoff option of git commit.
• Vital features and changes captured in unit and/or integration tests
• Commits messages follow AP format
• Extend the documentation, if necessary
• Merging to main from fork:branchname

[dselman]

This is risky imo because it opens up a scenario whereby deserialisation can break because you've simply added a new concept which extends an abstract type. This will be confusing to document and to understand.

[dselman]

It would be much safer (and more work!) if this was explicit in the model, via a final declaration. Properties, or arrays, of final types would never need $class when serialised or deserialised.

[dselman]

We could map final to sealed in C# and to final in Java.

[dselman]

We will also need to check the same logic applies to relationships.

--> IAddress address vs. --> Address address

[mttrbrts]

Closing in light of @dselman's comments.
#542 (comment)

[DS-AdamMilazzo]

I agree with Dan's comment about deserialization. The approach I recommend is to simply treat an object as an instance of the declared field type if it's not annotated. This should be even simpler to implement than this PR (because you don't have to care about how many concrete assignable types there may be), more general, and would not break in the case Dan describes.