A fix and a test case for Bug#34898 "mysql_info() reports 0 warnings
while mysql_warning_count() reports 1"

Review the patch by Chad Miller, implement review comments
(since Chad left) and push the patch.

This bug is actually not a bug. At least according to Monty.
See Bug#841 "wrong number of warnings" reported back in July 2003
and closed as "not a bug".
mysql_info() was printing the number of truncated columns, not
the number of warnings.
But since the message of mysql_info() was "Warnings: <number of truncated
columns>", people would expect to get the number
of warnings in it, not the number of truncated columns.

So a possible fix would be to change the message of mysql_info()
to say Rows changed: <n>, truncated: <m>.

Instead, put the number of warnings there. That is, remove the
feature that thd->cuted_fields (the number of truncated fields)
is exposed to the client. The number of truncated columns can be
calculated on the client, by analyzing SHOW WARNINGS output,
and in future we may remove thd->cuted_fields altogether.
So let's have one less thing to worry about.

client/mysqltest.cc:
  Fix a bug in mysqltest program which used to return
  a wrong number of affected rows in ps-protocol, and a wrong
  mysql_info() information in both protocols in presence of warnings.
mysql-test/r/insert.result:
  Update results (Bug#34898)
mysql-test/suite/rpl/r/rpl_udf.result:
  Update to the changed output of mysqltest: mysql_info() is now printed
  before warnings.
mysql-test/t/insert.test:
  Add a test case for Bug#34898.
sql/sql_table.cc:
  A fix for Bug#34898 - report statement warn count, not the
  number of truncated values in mysql_info().
sql/sql_update.cc:
  A fix for Bug#34898 - report statement warn count, not the
  number of truncated values in mysql_info().