Extraction of existing resource fields for validation needs refactoring

[lindyhopchris]

The implementation of extracting existing resource field values for validating an update request was brought in from the old package. There are two reasons why it needs refactoring:

1. It pulls the current values from the resource class; however this class can return things like conditional attributes, or it could contain JsonSerializable objects. This would result in these values being passed to the validation rules, which could then fail. What we actually need to do is encode the values to JSON and decode them to get the actual JSON:API field values.
2. We use the mustValidate method on the resource's relations. However, resources are now optional classes - so the mustValidate method should be moved to the schema relation field - which is a better place for it anyway.

The solution to both is probably to pass the existing model to the encoder to encode... and use the mustValidate method on the schema's relations to work out what include paths to pass in - i.e. to force the encoder to give us data members for the relationships that must be validated.

When doing this, we should encode to a JSON string, then decode... so that we get the actual JSON values for any objects that implement JsonSerializable.

It would be worth putting all this logic into a single class that is responsible for the conversion and merging with the values provided by the client. As this relates to validation the class should probably be in the laravel-json-api/validation package; and then the request classes in this package use that object to compute the validation data for an update request.