Refactoring MSMQSoapProvider for Generic Async Support

I had an epiphany the other day in which I realized there's no need for both the MSMQ
and MQSeries channels to have their own, dedicated SoapTransport.  Instead,
the transport itself is really quite generic.  It's
the transport-specific channel that we really care about.  Thus,
SoapAsyncTransport was born to service the needs of both queuing technologies.

SoapAsyncTransport's constructor takes a System.Type of a SoapChannel-derived class
and a string representing the scheme for the transport (i.e., soap.msmq or soap.mqseries.)  It
dynamically creates transport-specific channels as needed.

I bet the SMTP model could be brought into this model ...