Invalid FTP connection handling on blocked content.

FTP client gets stuck after the following chain of events:
 * Client requests a file that will be blocked by ICAP.
 * Squid starts downloading the file from the FTP server
   and sends "150 Opening..." to the FTP client.
 * Squid aborts the data connection with the FTP server
   as soon as the ICAP service blocks it.
 * Squid sends "451 Forbidden" to the FTP client.
 * The FTP server sends "500 OOPS: setsockopt: linger" to Squid.
 * Squid terminates the control connection to the FTP server.
 * Squid establishes a new control connection to the FTP server
   but does not authenticate itself.
 * Further commands from the FTP client do not work any more.

The above and many similar problems exist because Squid handles
FTP client-to-squid and squid-to-FTP server data connections
independently from each other. In many cases, one connection does
not get notified about the problems with the other connection.

This patch:
  - Add Ftp::MasterState::userDataDone to record received
    the FTP client final response status code to sent (or to be send)
    to the client.
  - The Ftp::MasterState::waitForOriginData flag to hold status of the
    squid-to-server side. If the squid-to-server side is not finishes
    yet this is true.
  - Send a control reply to the FTP client only after the data transfered
    on both server and client sides.
  - Split Client::abortTransaction to Client::abortOnData and to
    Client::abortAll()
  - Implement the Ftp::Relay::abortOnData() and Ftp::Relay::Abort()
    (i.e., StoreEntry abort handler) to avoid closing the control
    connection when the data connection is closed unexpectedly.

This is a Measurement Factory project.