Always include to_one linkage

[lgebhardt]

This PR reenables the always_include_to_one_linkage_data configuration option. This joins in the to_one relationship in order to retrieve the linkage data without additional database requests.

The path parsing logic for includes, filters and sorts was moved to a Path class that parses into Relationship and Field path parts.

Filtering is extended across polymorphic relationships.

Enables the a new join_left ponyfill to extend left_joins to rails 4 and works around an issue with nested joins not aliasing correctly on rails 5 and 5.1.

Streamlines the JoinTree and Joins handling of polymorphic relationships in paths. Filters can now specify the specific resource type of a polymorphic relation using the format relationshipname#resource_type. For example pictures.imageable#document.name

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

[joegaudet]

A few comments, largely looks good.

The polymorphic resource specification stuff is interesting, I take it not part of the JSONAPI spec though?

[joegaudet]

So there's no way for me to say that the broad configuration is always included, but for one relationship do not? Not that I think this is a likely case, but a case nonetheless.

[lgebhardt]

It's not supported for ActiveRecord whether set globally or per relationship. The code just doesn't exist yet, and it's going to potentially be expensive so I'm not planning to tackle it soon.
What do you think the best way to handle this in the relationship would be? Conceivably we could write a Mongo adapter that easily supports this. I want the Relationship to work with either Adapter. We could interrogate the Adapter for capabilities.

[dgeb]

Let's deprecate Resource#find_records properly to discourage its use.

[lgebhardt]

@joegaudet, @dgeb Thanks for the reviews. I think I've got all the suggestions implemented or addressed, with the exception of deprecating the find_records method. I'm still looking for a good way to handle that so people who have it overridden can be notified they may need to change it. As it is now it will at least fail so I haven't renamed the method. Any suggestions?