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.
Since we don't modify `tags` in this filter, do we want to include it when calling the next service? Open question for discussion, rather than leading!