Safaricom is moving away from SMPP to ParlayX 2.1

In infinite wisdom they are moving away from a persistent socket based standard to a SOAP based deprecated standard called [ParlayX](http://en.wikipedia.org/wiki/Parlay_X).

WSDLs available, ping me over email if needed.

Expected deliverable is a [Vumi Transport](https://github.com/praekelt/vumi/blob/develop/vumi/transports/base.py) implementation:

1. that accepts MO messages via SOAP calls from Safaricom's ParlayX services.
2. that allows for MT message delivery via SOAP calls to Safaricom's ParlayX services.
3. that accepts delivery reports for MT messages via SOAP calls from Safaricom's ParlayX services.
4. tests that can be run with `trial` and which use our [TransportTestCase](https://github.com/praekelt/vumi/blob/develop/vumi/transports/tests/utils.py#L7) base class. This provides convenience methods for setting up & tearing down the worker and stubs out all of the AMQP machinery with a FakeAMQP implementation (compliments of @jerith).
5. General approach we take with this stuff is to fire up a separate service that mocks the remote side of the transport (in this case Safaricom) which is used to make assertions on outbound calls and generate fake responses. See the [Apposit test case](https://github.com/praekelt/vumi/blob/develop/vumi/transports/apposit/tests/test_apposit.py#L23-L27) for an example of the service and [how it is used in a test](https://github.com/praekelt/vumi/blob/develop/vumi/transports/apposit/tests/test_apposit.py#L273)