New FTP CCC functionality - adds passive and active mode to accomodate for different server behaviour

New FTP CCC functionality - adds passive and active mode to accomodate for different server behaviour

part of the official libcurl API http://curl.haxx.se/lxr/source/lib/README.curlx
The documented way of using them would be to use timeval.c as a source code file.

The above described method works very well when statically linking libcurl and
apps, curl tool, but has several drawbacks when you build a true shared
libcurl (i.e. Name space clash at linkage stage as functions are defined more
than once. Windows makefiles are not capable of handling this system of
source-level sharing)

So...

Now curlutil.h and curlutil.c define and implement cutil_tvnow and cutil_tvdiff
which replace curlx_tvnow and curlx_tvdiff for the curl tool. Doing this we
avoid the above described problems.

struct for platforms that don't have it to setup_once.h

1) The maketgz script does not insert the timestamp in curlver.h,
   it actually updates it. For CVS versions it is the "CVS" string.

2) testcurl.pl will always print the "date" string which represents
   the moment the test build is run.

3) testcurl.pl may not print the "timestamp" string since the script
   may end before it is printed out. (i.e. unable to update from CVS)

4) The "timestamp" string printed will be the same as the "date" one
   unless one of the following conditions is met.

   *) It is a tarball-based build. Timestamp will be creation time.

   *) CVS update has been done. Timestamp will be end of CVS update.

for tarball-based tests and builds, the maketgz script inserts it when
the tarball is created. For CVS-based tests and builds the timestamp we
show is the current UTC build time as it is the CVS version timestamp.

In this way, all builds will have a valid source code timestamp which
isn't related to the moment the tests and build is performed, with the
exception of CVS-based ones which have the same "date" and "timestamp"

AC_PATH_PROG was not used properly.

  when the multi interface was used.

  5).

  the multi interface and connection re-use that could make a
  curl_multi_remove_handle() ruin a pointer in another handle.

  The second problem was less of an actual problem but more of minor quirk:
  the re-using of connections wasn't properly checking if the connection was
  marked for closure.

linked to the networking libraries.

and those required by other components to avoid forcing unneeded
dependencies into the target objects.