RequestParser and LinksBuilder rework

Some recent PRs and Issues (#928, #951, and a few issues related to links generation) have had me thinking about the deficiencies in the RequestParser architecture.

Request parsing is largely hidden behind the RequestParser which takes JSONAPI formatted requests and turns them into Operations which are then executed by a resource specific Processor (or the default Processor). A RequestParser is instantiated by the controller but beyond that it's out of the users control without monkey patching the RequestParser.

Instead of having a custom action parsed differently from the standard actions I'd like to rework the request parsing stage so custom actions would be handled in the same way as the standard defined actions.

I'm proposing we move the RequestParser logic in the controller to allow easy addition of custom actions and overriding of the existing actions. This could be done in a series of modules with core behavior in one and actions for V1 and the new Operations spec (#951) in another.

In addition the LinksBuilder generates links for routes/actions which may not exist. I'd like to tie the link building to the routes supported by the controller. The changes to support the custom actions will need changes to the links generation so this seems like a good time to tackle this too.

Thoughts?

The issue names RequestParser, controller logic, LinksBuilder, custom actions, and the Operations spec in #951, but no files or tests. Start by tracing how the controller instantiates RequestParser and how LinksBuilder derives routes. Done means custom and standard actions share the revised parsing path and generated links only target controller-supported routes.