Store the resource_klass and id in an array for efficiency

[lgebhardt]

Removes the need to allocate a new array for every comparison.

Found a large number of allocations in the hash method when profiling the code. This removes about 35K allocations from a result set that contained about 3500 resources (1000 primary with 2500 includes). Not surprisingly that doesn't actually make a statistically significant performance issue for small requests like the one tested, but every little bit helps.

Also changes the eql? to use the hash method

All Submissions:

• I've checked to ensure there aren't other open Pull Requests for the same update/change.
• I've submitted a ticket for my issue if one did not already exist.
• My submission passes all tests. (Please run the full test suite locally to cut down on noise from travis failures.)
• I've used Github auto-closing keywords in the commit message or the description.
• I've added/updated tests for this change.

New Feature Submissions:

• I've submitted an issue that describes this feature, and received the go ahead from the maintainers.
• My submission includes new tests.
• My submission maintains compliance with JSON:API.

Bug fixes and Changes to Core Features:

• I've included an explanation of what the changes do and why I'd like you to include them.
• I've provided test(s) that fails without the change.

Test Plan:

Reviewer Checklist:

• Maintains compliance with JSON:API
• Adequate test coverage exists to prevent regressions

[bf4]

Looks good

[bf4]

Interesting that eql? and <=> diverge in what they compare but is out of scope to this change

[lgebhardt]

For <=> it really should be comparing the resource_klasses first and then the ids second to determine the response. I think that would only affect the ordering of identities in the related identities when we're using a SortedSet and storing identities for a polymorphic relationship. It looks like that comparison can be done without any allocations so it's probably a good idea to make the change, but I'll handle that in a separate PR.