FalseStart - client becomes unsuable if transport fails during start request

If a transport failed during the start request or if the start request failed we would not fail the transport or throw an exception leaving the transport in kind of a zombie state. The reason for this was that we used `SafeThreadInvoker` to start the start request which invalidated any further `Fail` calls. When AutoTransport was being used we would always try the next transport even though the correct behavior was to throw from the `Start` method if the connect request completed successfully and a failure occured during start request. The fix is to not to use SafeThreadInvoker to start the start request. In addition we have to track the state of the initialization phase to prevent failing the transport due to timeout once the connect request completed successfully and to throw the StartException after connect request completed successfully to let the AutoTransport know to not try the next available transport but to re-throw the exception.
Because we are using ThreadSafeInvoker for both Complete/Fail operations only one of them can be executed. Note that `Dispatch` is invoked from within `ThreadSafeInvoker.Invoke` which means we will never have two `Dispatch` invocations in flight. 
All the transport implementations do clean up on their side if a transport fails in addition to calling the TransportFailed.