Fix appconnect time problematic accumulation when using TLS-in-TLS proxy

[MrDwZ]

Follow up this email list thread.
We use a TLS-in-TLS HTTPS proxy with proxy client auth required setup, the appconnect time accumulated twice and exceeds the total time.
I found this seems to caused by a potential bug in Curl_pgrsTime, the problem is when we use TLS-in-TLS proxy, Curl_ssl_connect_nonblocking called twice, as we need to build TLS connection to proxy and followed by destination. See this stack trace. The current implementation would be:

1. When connect to proxy: t_appconnect = now - t_startsingle
2. When connect to destination: t_appconnect = t_appconnect + (now - t_startsingle)

My commit changes t_appconnect to only record the time that TLS has been established to destination, as both TLS connection finished.

I know we accumulate some timerid because of redirection, any suggestion would be welcome if there's anything is wrong with this PR. :-)

I tested by building locally and the appconnect time is less than all the following time.
Before

curl $([my proxy config]) -v -s -w "@curl-format.txt"  -o /dev/null https://www.google.com 
  time_namelookup: 0.000108
       time_connect: 0.199598
    time_appconnect: 0.443684
   time_pretransfer: 0.233842
time_starttransfer: 0.273798
                    ----------
         time_total: 0.276055

After

curl $([my proxy config]) -v -s -w "@curl-format.txt"  -o /dev/null https://www.google.com
    time_namelookup:  0.000060
       time_connect:  0.199511
    time_appconnect:  0.227428
   time_pretransfer:  0.227497
 time_starttransfer:  0.329309
         time_total:  0.329540

[bagder]

Thanks! I'm not super happy about adding more special-purpose state bits to the Curl_easy struct, but after reading your PR and patch I created an alternative take on this (that should fix the same issue) that I'd love your comments on: #7275

[MrDwZ]

merge the discussion into #7275