Keep relationship data when linking items from included

[JaZo]

Description

I've changed the relationship classes so they can store both data and included.

Motivation and context

#89 fixed a bug where meta in relationship data was ignored. However, when an item that has meta in it's relationship data is included, it is overwritten by the item from the included. Removing access to that meta.

Use case

Given the following JSON:

{
	"data": {
		"type": "parent",
		"id": "1",
		"attributes": {
			"foo": "bar"
		},
		"relationships": {
			"child": {
				"data": {
					"type": "child",
					"id": "1",
					"meta": {
						"a": "foo"
					}
				}
			}
		}
	},
	"included": [{
		"type": "child",
		"id": "1",
		"attributes": {
			"foo": "baz"
		}
	}]
}

It was not possible to use the meta from the relationship ({"a": "foo"}), as the entire item would be overwritten by the included item. So when you get the meta from the related item, you get null as there is no meta in included.

New situation

$document->getData()->getRelation('child')->getData()->getMeta() > {"a": "foo"}
$document->getData()->getRelation('child')->getIncluded()->getMeta() or $document->getData()->child->getMeta() > null

N.B.

To make this fix backwards compatible, a relationship's included is filled, even when the item(s) are not actually included. In the next major version, we can choose to make this more strict and only fill the included when the item is actually included.

How has this been tested?

I've added new tests.

Types of changes

What types of changes does your code introduce? Put an x in all the boxes that apply:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

Go over all the following points, and put an x in all the boxes that apply.

• I have read the CONTRIBUTING document.
• My pull request addresses exactly one patch/feature.
• I have created a branch for this patch/feature.
• Each individual commit in the pull request is meaningful.
• I have added tests to cover my changes.
• If my change requires a change to the documentation, I have updated it accordingly.