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.

Workitem: 3227
XUnit++ - updating XUnit 2.0 to beta-4
RespectMe - respecting disconnect token in store WebSocketTransport

The store WebSocketTransport did not respect the disconnect token. Now if the disconnect cancellation token is cancelled we will not try to reconnect if the websocket gets closed and if we are already trying to reconnect we will stop doing this. Note that we don't need to register to the cancellation event since the disconnect cancellation token is cancelled only in the `Connection.Disconnect()` method which also disposes the transport which will take care of the all needed clean up.

Also fixed a race in the WebSocketTransport.Dispose method which might lead to unwanted reconnection attempts.

Workitem #3189