HTTP: return larger than 3 digit response codes too

HTTP 1.1 is clearly specified to only allow three digit response codes,
and libcurl used sscanf("%3d") for that purpose. This made libcurl
support smaller numbers but not larger. It does now, but we will not
make any specific promises nor document this further since it is going
outside of what HTTP is.

Bug: http://curl.haxx.se/bug/view.cgi?id=1441
Reported-by: Balaji
mk-ca-bundle: spell fix "version"
Debug output 'typo' fix.

Don't print an extra "0x" in
* Pipe broke: handle 0x0x2546d88, url = /
Don't add new requests to a closed pipeline.

This single commit fixes seemingly all problems that I had:
After a requests times out it marks the conn(ection) as 'close'
by calling connclose() and then stopped handling the easy
handle *completely* - hence the connection is never (really)
closed, the bundle is kept alive and never removed, and with
this commit a following active request creates a new connection
in the bundle, which is the one being used after that - because
the one that had 'close' set is skipped.

However, this -therefore- leaks: the connection is never closed
(by the client), nothing is cleaned up.

After the commits that follow, this commit is no longer needed,
but it makes sense to keep it; after all: we really do NOT ever
want to use a connection that is marked as 'close' here.

The remaining problem: leaking and not closing the socket is
addressed in the following commits.
Fix a leak and close the connection of a request that timed out.

This fixes a four year old bug; when a request times out, then
setting CURLM_STATE_COMPLETED here, followed by a break, causes
the code to continue at the end of the function where the
message is sent to the user with multi_addmsg() after which
the state is set to CURLM_STATE_MSGSENT.

An easy handle in that state never gets out of that state anymore:
the state does nothing. Cleaning up the easy handle from the user
application (after seeing the request is CURLMSG_DONE) doesn't
change that fact. As a result, the easy handle gets stuck, owning
a connection set to 'close' that is never closed or cleaned up.

This commit set to the state to CURLM_STATE_DONE and does NOT break
out of the loop. As a result the easy handle is cleaned up as a
handle with an error, as it should. It's connection is closed.

However, problems remain after this:
1) Because this was (likely) the last connection, the bundle is deleted
   as well now; which results in libcurl forgetting that this server
   can do pipelining. The new connection that is created for subsequent
   requests, or for handles in the pipeline after this one that didn't
   time out cause new connections to be created until we finally
   receive headers for one of them. This is a random process and we
   can end up any arbitrary number of connections; which afterwards
   will NOT desolve itself (they will all kept being used).
2) The requests that were still in the pipeline will attempt a new
   connection - then discover they have timed out and ALSO call
   connclose, causing the JUST created fresh connection to be closed
   too. The result is a rapid brust of calls to connect() and close().

Both problems are addressed in subsequent commits because they are
exclusively pipeline related, while this commit isn't.
On timeout, do not close connections with NO pending data.

When pipelining it is possible that a request never reached
the DO state, but still timed out because a request in the pipeline
before it took a long time.

The logic of curl is such that first a new connection is created
and only then the handles on it are checked for time outs, hence
it is possible that a handle times out without ever having sent
a GET request over their connection. In that case we don't want
to close that connection: it is a healthy connection that probably
was JUST created as replacement for the broken pipe at which the
timeout really occurred.

Although this commit fixes the burst of connect()/close() calls,
the problem remains that the bundle to the server was refreshed,
so curl forgot about this server being able to do pipelining.
This is fixed in the next commit.
Prevent a bundle being deleted while closing a broken pipe.

If a request on a pipe times out, it breaks that pipe: the
connection needs to be closed. However, when doing http pipelining
we really don't want to delete the bundle and forget that this
server can do pipelining because that results in a separate connection
for every handle in the pipeline that didn't timeout yet, plus one
for every handle that is added until we receive new headers from the
server again, potentially a lot.

The user application could battle this a little bit by holding back
on adding new requests when it sees a timeout, until it saw a reply
again from the server - but that is an extra burden on the user
application that is unnecessary. Besides, that doesn't guarantee that
multiple connections wonn't formed due to requests already in the
pipe that didn't timeout yet (i.e. because they were added later than
the one that did).

Although theoretically this is still a leak of the bundle (though note
that before this series of commits it was ALREADY leaking), in practice
a new request WILL*) be added and the bundle will be reused without any
trace of a leak.
*) After all, we're talking about a pipelining server here :p.
TODO: consider supporting STAT
code cleanup: We prefer 'CURLcode result'
sasl_sspi: Fixed typo in comment
Check for ALPN via OpenSSL version number.

This check works also with to non-configure platforms.
Fixed error message since we require ALPN support.
Added NetWare support to build with nghttp2.
openssl: fix a line length warning
nss: drop the code for libcurl-level downgrade to SSLv3

This code was already deactivated by commit
ec783dc142129d3860e542b443caaa78a6172d56.
transfer: drop the code handling the ssl_connect_retry flag

Its last use has been removed by the previous commit.
sasl_sspi: Allow DIGEST-MD5 to use current windows credentials

Fixed the ability to use the current log-in credentials with DIGEST-MD5.
I had previously disabled this functionality in commit 607883f13c as I
couldn't get this to work under Windows 8, however, from testing HTTP
Digest authentication through Windows SSPI and then further testing of
this code I have found it works in Windows 7.

Some further investigation is required to see what the differences are
between Windows 7 and 8, but for now enable this functionality as the
code will return an error when AcquireCredentialsHandle() fails.
sspi: Return CURLE_LOGIN_DENIED on AcquireCredentialsHandle() failure

Return a more appropriate error, rather than CURLE_OUT_OF_MEMORY when
acquiring the credentials handle fails. This is then consistent with
the code prior to commit f7e24683c4 when log-in credentials were empty.
vtls.c: Fixed compilation warning

conversion from 'size_t' to 'unsigned int', possible loss of data
Add debug output and fix comment.

Also print the number of connections in the connection cache when added
one, and not only when one is removed.