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
TheFirstPlaceLoser - removing unnecessary calls to `TransportFailed`

`ServerSentEventsTransport` and `LongPollingTransport` registered callbacks to let the `TransportInitializationHandler` know that the transport failed (by calling the `TransportFailed` method) when the `disconnectToken` is tripped . This was unnecessary since the `TransportInitializationHandler` registered first its own callback for the same reason which would call `TransportInitializationHandler.Fail()`. Because we use the `SafeThreadInvoker` for invoking the `Fail()` method the calls from the transport implementations were no-ops because they would have happened after the call from the `TransportInitializationHandler` which in turn would make `SafeThreadInvoker` ignore any further calls.