Bugfix for typealias/associatedtype conflict.

One protocol's typealias will collide with another protocol's associatedtype in very ugly ways. This is why for now we will have ResourceObject.ID and ResourceObject.Id (both equally valid ways of referring to a ResourceObject's Identifying type.

Bugfix for ResourceObjectProxy

Attempt to fix a bug that only shows up in edge cases where ResourceObjectProxy.ID is used directly and must be equal to ResourceObject.ID.

Adds Swift `Identifiable` conformance to `ResourceObject`

In order to reduce the burden of conflict on users of the library, JSONAPI.Identifiable has been renamed to JSONAPIIdentifiable and (for all platforms that support it) conformance to Swift.Identifiable has been added to ResourceObject.

⚠️ Breaking Changes ⚠️
Sorry to introduce a breaking change during the release candidates. Conformance to Swift.Identifiable is really beneficial, especially if you ever pull a model into SwiftUI.

• Renamed Identifiable -> JSONAPIIdentifiable
• Renamed JSONAPIIdentifiable's Identifier associated type to ID to match that of the Swift Identifiable type.
• Removed ResourceObject.Id (i.e. consolidated so that the same type alias as is used by JSONAPIIdentifiable and Swift.Identifiable is just named ResourceObject.ID). Otherwise there is a confusing co-existence of both ResourceObject.ID and ResourceObject.Id.
• [EDIT] As of the soon-to-be-released 4.0.0-rc.3.2, I will have re-introduced ResourceObject.Id which means that ResourceObject.ID and ResourceObject.Id will be equally valid. Not crazy about it, but no easy and satisfactory way to deal with it before the release of 4.0.0.

Suggested approach to updating code:

1. Anywhere you are using JSONAPI.Identifiable, find JSONAPI.Identifiable or Identifiable (careful not to pick up on Swift Identifiable in your codebase) and replace with JSONAPIIdentifiable.
2. Anywhere you are using Identifier() or Id() in the context of a ResourceObject to construct its ID, replace with ID(). [EDIT] As of 4.0.0-rc.3.2 ResourceObject.ID and ResourceObject.Id will both be equally valid.

Add relatives filtering to CompoundResource

Adds filtering of related resources to CompoundResource.

4.0 Release Candidate 1

Changes since Alpha 3:

• Add CompoundResource
• Add SucceedableJSONAPIDocument and FailableJSONAPIDocument protocols
• Make ResourceObject Hashable when its Id is Hashable.
• Make Id's Hashable conformance take its type into consideration since the Id type's primary motivation is to retain differentiation based on the type of thing being identified.

Additional abstraction points around resource body

Expose abstraction points around single and many resource bodies that allow generic extensions to access the primary resource value(s).

Adds a couple of convenience initializers on Document types.

Merge pull request #65 from mattpolzin/feature/add-initializers

Add some convenience initializers

Fix inability to represent Relationship Objects with no `data` property.

Fixes #56.

This is a niche issue, but now a MetaRelationship can be used in place of a ToOneRelationship or ToManyRelationship when a Relationship Object with only links and/or meta is needed.

First 4.0 Alpha Release

• Bump minimum Swift version to 5.2
• Remove deprecated subscript access to ResourceObject attributes.
• Fix/Improve errors during decoding caused by malformed ResourceObject relationships.
• Modify Document.SuccessDocument to guarantee non-optional properties where the fact that it is a success document is able to provide such guarantees. For example, .primaryResource and .includes are now non-optional on SuccessDocument.

New testing feature and _much_ better errors

• Adds JSONAPITesting framework compare(to:) functions that deliver concise comparisons of two documents or resource objects. Just print the String(describing:) a comparison to get a human readable description of the differences.
• Adds ResourceObjectDecodingError and DocumentDecodingError which represent more JSON:API-specific errors and come with good string descriptions for many common reasons why JSON:API resources or documents could fail to decode. Just catch the error from decoding a ResourceObject or Document and save or print String(describing: error).

---

⚠️ Breaking Changes ⚠️

📛 Renames JSONAPIDocument to CodableJSONAPIDocument.
📛 Renames OptionalPrimaryResource to OptionalCodablePrimaryResource.
📛 Renames PrimaryResource to CodablePrimaryResource.
📛 Renames ResourceBody to CodableResourceBody.
📛 Renames PolyWrapped to CodablePolyWrapped.
📛 Renames SingleResourceBody.Entity to SingleResourceBody.PrimaryResource
📛 Renames ManyResourceBody.Entity to ManyResourceBody.PrimaryResource
📛 Renames JSONAPIEncodingError to JSONAPICodingError

⛔️ Deprecates subscript access of ResourceObject attributes in favor of key path dynamic member lookup.

🗑 Removes key path dynamic member lookup of Document properties on Document.SuccessDocument and Document.ErrorDocument in favor of directly providing relevant accessors (see SuccessDocument/ErrorDocument for details).