Move features of MatrixHttpApi related to application-services into subclass

See discussion on #143.

In general, I want to move the sdk more towards a set of composable classes with a clear api for extending them. Something where parameters specific to application-service usage live either in an additional kwarg `extras` or in slurped kwargs `**extras` seems like the right direction for this.

Issues to be resolved still:

- [ ] What if somebody wants to combine functionality available on two different subclasses of `MatrixHttpApi` (e.g. application-service support and async as in #168)? We should support composing those together somehow.

Maybe in addition to swapping out `_send` we should have a list of decorators that get applied to `_send`?

cc @Cadair

Start by reading MatrixHttpApi and the discussion on #143, then review the related async proposal in #168. Done means application-service functionality is moved into a composable subclass or extension, while the issue's unresolved combination of application-service and async behavior has a defined solution.

Written by the indexing model from the issue text.