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?

La issue nomina RequestParser, la logica del controller, LinksBuilder, le azioni personalizzate e la specifica Operations in #951, ma non indica file o test. Inizia tracciando il modo in cui il controller istanzia RequestParser e il modo in cui LinksBuilder ricava le route. Il lavoro è completato quando le azioni personalizzate e standard condividono il percorso di parsing rivisto e i link generati puntano solo a route supportate dal controller.