~40Mb after mysqldump/import 
        
When the input string exceeds the maximum allowed size for the 
internal buffer, batch_readline() returns a truncated string. 
Since there was no way for a caller to determine whether the 
string was truncated or not, the command line client assumed 
batch_readline() to always return the whole input string and 
appended a newline character. This resulted in garbled data 
when importing dumps containing strings longer than the 
maximum input buffer size. 
  
Fixed by adding a flag to the batch_readline() interface to 
signal a truncated string to the caller. 
  
Other minor problems fixed during patch implementation: 
 
- The maximum allowed buffer size for batch_readline() was set 
up depending on the client's max_allowed_packet value. It does 
not actully make any sense, as those variables are not 
related. The input buffer size limit is now always set to 1 
MB. 
  
- fill_buffer() did not always set the EOF flag. 
 
- The input buffer could actually grow twice as the specified 
limit due to insufficient checks in intern_read_line(). 

client/my_readline.h:
  Changed the interface of batch_readline().
client/mysql.cc:
  Honor the truncated flag returned by batch_readline() and do  
  not append the newline character if it was set. Since we can't 
  change the interfaces for readline()/fgets() used in the  
  interactive mode, always assume the returned string was not  
  truncated. In addition, always set the batch_readline()  
  internal buffer to 1 MB, independently from the client's  
  max_allowed_packet.
client/readline.cc:
  Added the 'truncated' argument do batch_readline() to signal 
  truncated string to a caller. 
  Fixed fill_buffer() to set the EOF flag correctly. 
  Fixed checks in intern_read_line() to not allow the internal  
  buffer grow past the specified limit.
mysql-test/r/mysql.result:
  Added a test case for bug #41486.
mysql-test/t/mysql.test:
  Added a test case for bug #41486.