PurePollution - changing the way we inject factories

Before we would create factories in the `connection` class and pass references to them when creating the `connection_impl` instance. In the long run this won't work for at least couple of reasons:
- transports will have to have a reference to the `connection_impl` to be able to let connection know about events (e.g. message received, disconnected, error etc). As a result to create a transport a (smart) pointer to the `connection_impl` will have to be passed to the `transport_factory.create()` method. However this would require making the `connection_impl type` (and all types it uses) public because the factories are members of a public (i.e. the `connection`) type. An alternative is to use uniqe pointers which will be set to default factories in the `connection_impl` itself. Tests will still be able to inject their own implementation. An additional advantage of using pointers is that now we can hide a few types that were only exposed because we had references in the connection class and since the references are gone the types don't have to exposed anymore.
- because transports will have to have a back pointer to a `connection_impl` instance it will be possible that the `connection_impl` instance will outlive the `connection` object itself (think about tasks that captured a pointer to `connection_impl` and that running after the `connection` object goes out of scope). In this scenario the transport/`connection_impl` may want to use factories while they were already destroyed because they were members of an object that has already been destroyed. This would result in undefined behavior and most likely a crash. Moving factories to the `connection_impl` fixes this issue (note: currently the `connection` type holds a raw pointer to a `connection_impl` instance which is `delete`d in the `connection`'s dtor; this will have to be changed (most likely by changing the raw pointer to a smart pointer) to prevent from trying to use an already disposed pointer in transports - same as above)
As a result of this change we are 'polluting' the code base with smart pointers but the public surface is cleaner than before.
This: http://herbsutter.com/gotw/_100/ is still open in my browser :) 
The interesting part is:
_You still need to write the visible class’ destructor yourself and define it out of line in the implementation file, even if normally it’s the same as what the compiler would generate. This is because although both unique_ptr and shared_ptr can be instantiated with an incomplete type, unique_ptr’s destructor requires a complete type in order to invoke delete (unlike shared_ptr which captures more information when it’s constructed). By writing it yourself in the implementation file, you force it to be defined in a place where impl is already defined, and this successfully prevents the compiler from trying to automatically generate the destructor on demand in the caller’s code where impl is not defined._
There are also numerous threads on SO about this - I spent a good chunk of yesterday working through it. 

compilation time (while longer than C#'s) is not a concern (yet...)