Moved 144 to 7.18.3 instead

  the curl_multi_socket() API with HTTP pipelining enabled and could lead to
  the pipeline basically stalling for a very long period of time until it took
  off again.

  provided excellent repeat recipes. I fixed the cases I managed to reproduce
  but Jeff still got some (SCP) problems even after these fixes:
  http://curl.haxx.se/mail/lib-2008-05/0342.html

due to KfW's library header files exporting symbols/macros that should be
kept private to the KfW library. See ticket #5601 at http://krbdev.mit.edu/rt/

  how the HTTP redirect following code didn't properly follow to a new URL if
  the new url was but a query string such as "Location: ?moo=foo". Test case
  1031 was added to verify this fix.

144 - Help apps use 64bit/LFS libcurl

openssl/objects.h were needed to compile SPNEGO support.

releases

the dist tarball and remove a two duplicate file names from EXTRA_DIST
(most of it pointed out by Yang Tse)

for 7.18.2 since we have added functions in this release.

http://curl.haxx.se/mail/lib-2008-05/0240.html

libtest code.

to curl_easy_setopt instead of long.

in the tarball

script will simply issue a warning and gethostbyname() will be used.

_ Updated packages/OS400/curl.inc.in with new definitions.
_ New connect/bind/sendto/recvfrom wrappers to support AF_UNIX sockets.
_ Include files line length shortened below 100 chars.
_ Const parameter in lib/qssl.[ch].
_ Typos in packages/OS400/initscript.sh.

  interface problems:

  o with pipelining disabled, the state should never be set to WAITDO but
    rather go straight to DO

  o we had multiple states for which the internal function returned no socket
    at all to wait for, with the effect that libcurl calls the socket callback
    (when curl_multi_socket() is used) with REMOVE prematurely (as it would be
    added again within very shortly)

  o when in DO and DOING states, the HTTP and HTTPS protocol handler functions
    didn't return that the socket should be waited for writing, but instead it
    was treated as if no socket was needing monitoring so again REMOVE was
    called prematurely.

go straight to DO

we had multiple states for which the internal function returned no socket at
all to wait for, with the effect that libcurl calls the socket callback (when
curl_multi_socket() is used) with REMOVE prematurely (as it would be added
again within very shortly)

handler functions didn't return that the socket should be waited for writing,
but instead it was treated as if no socket was needing monitoring so REMOVE
was called prematurely