Versions, not to ./Versions and indentation improvments

2006. It turned out we wrongly assumed that the connection cache was present
when tearing down a connection.

multi interface, but I could also repeat it doing multiple sequential ones
with the easy interface. Using Ciprian's test case, I could fix it.

CURLOPT_VERBOSE set to non-zero, you still got a few debug messages from the
SSL handshake. This is now stopped.

KNOWN_BUGS #25, which happens when a proxy closes the connection when
libcurl has sent CONNECT, as part of an authentication negotiation. Starting
now, libcurl will re-connect accordingly and continue the authentication as
it should.

case when 401 or 407 are returned, *IF* no auth credentials have been given.
The CURLOPT_FAILONERROR option is not possible to make fool-proof for 401
and 407 cases when auth credentials is given, but we've now covered this
somewhat more.

You might get some amounts of headers transferred before this situation is
detected, like for when a "100-continue" is received as a response to a
POST/PUT and a 401 or 407 is received immediately afterwards.

Added test 281 to verify this change.

reading the (local) CA cert file to let users easier pinpoint the actual
problem. CURLE_SSL_CACERT_BADFILE (77) is the new libcurl error code.

to the CURLOPT_DEBUGFUNCTION callback has been fixed (it was erroneously
included as part of the header).  A message was also added to the
command line tool to show when data is being sent, enabled when
--verbose is used.

to a multi stack will cause CURLM_BAD_EASY_HANDLE to get returned.

and while doing so it became apparent that the current timeout system for
the socket API really was a bit awkward since it become quite some work to
be sure we have the correct timeout set.

Jeff then provided the new CURLMOPT_TIMERFUNCTION that is yet another
callback the app can set to get to know when the general timeout time
changes and thus for an application like hiperfifo.c it makes everything a
lot easier and nicer. There's a CURLMOPT_TIMERDATA option too of course in
good old libcurl tradition.

now runs fine.

would crash if a bad function sequence was used when shutting down after
using the multi interface (i.e using easy_cleanup after multi_cleanup) so
precautions have been added to make sure it doesn't any more - test case 529
was added to verify.

Vista (_WIN32_WINNT >= 0x0600)

encrypt the control connection and use the data connection "plain".

it now will read the full data sent from servers. The SOCKS-related code was
also moved to the new lib/socks.c source file.

empty password or no password at all. Test case 278 and 279 were added to
verify.

  handle that is part of a multi handle first removes the handle from the
  stack.

- Added CURLOPT_SSL_SESSIONID_CACHE and --no-sessionid to disable SSL
  session-ID re-use on demand since there obviously are broken servers out
  there that misbehave with session-IDs used.

don't expect fully qualified names we need to cut them off at the first dot.

of them can be completetly removed though...

cache within the multi handle.

  while not fixing things very nicely, it does make the SOCKS5 proxy
  connection slightly better as it now acknowledges the timeout for connection
  and it no longer segfaults in the case when SOCKS requires authentication
  and you did not specify username:password.

name resolves. It could get stuck in the wrong state.

allow applications to set their own socket options.

properly if you removed a "live" handle from a multi handle with
curl_multi_remove_handle().