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.
I think there is a possible race here where if `InitReceived` is called immediately after this check we could move into the `AfterConnect` state before the `Interlocked.Exchange` in `CompleteFail` executes.

If this occurs, we will throw a `StartException` instead of a `TimeoutException` and the `AutoTransport` will not attempt to fallback.

I think the workaround is to turn this into:

    if (Interlocked.CompareExchange(ref _state, InitializationState.Fail, InitializationState.Initial) ==
        InitializationState.Initial)