Service composition refactor

* Replace context dependencies with responder
* Segregate responder interface from context (adapter) interface
* Add helper methods to application for service composition

May consider using objects for lazy execution and composition of service
objects as these are easier to inspect on the console.

This allows aspects, filters and services to be composed together and leverages Ruby keyword arguments to allow objects to enforce the presence of particular keywords while passing through others transparently. Services then only receive the arguments they need rather than risking exposure to all user input.
I had the same thought but that doesn't allow for optional parameters. If we don't care about that then I'm more than happy to make that change.