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?

Das Issue nennt RequestParser, die Controller-Logik, LinksBuilder, benutzerdefinierte Aktionen und die Operations-Spezifikation in #951, aber keine Dateien oder Tests. Beginne damit nachzuverfolgen, wie der Controller RequestParser instanziiert und wie LinksBuilder Routen ableitet. Als erledigt gilt die Aufgabe, wenn benutzerdefinierte und standardmäßige Aktionen denselben überarbeiteten Parsing-Pfad verwenden und generierte Links nur auf vom Controller unterstützte Routen verweisen.