Connectors and endpoints for workers

We currently have a collection of publishers and consumers which represent "connectors" on vumi workers through which messages arrive and depart. We need a higher-level object to group these together into a single unit and remove a lot of the complexity of setting them up. We also need to support multiple "endpoints" on these connectors to allow more complex message routing without an explosion of publishers and consumers.

The general idea is that we'll add `ReceiveInboundConnector` and `ReceiveOutboundConnector` classes to wrap and manage the publishers and consumers. Each connector class will support multiple consumer functions for different endpoint names. An endpoint name of `None` will handle messages without an endpoint name set and a default handler will process messages which do not match any configured endpoint handlers. Messages may be published with an endpoint name, defaulting to `None`.

Most (all?) transports will have a single `ReceiveOutboundConnector` and most (all? except maybe some legacy) applications will have a single `ReceiveInboundConnector`. Dispatchers will need at least one of each, probably more on one side or the other.

Backwards compatibility should be fairly straightforward for transport and application infrastructure, except perhaps for complex applications that already handle multiple sets of publishers and consumers. Old dispatchers will be tricky to support and this may be a good time to deprecate the current dispatcher infrastructure (which is crufty and problematic anyway) and build something cleaner that supports connectors and endpoints properly. If we do this, we can almost certainly add some "plumbing" dispatchers to translate between legacy and endpoint-aware workers.