with on duplicate key update

There was a missed corner case in the partitioning
handler, which caused the next_insert_id to be changed
in the second level handlers (i.e the hander of a partition),
which caused this debug assertion.

The solution was to always ensure that only the partitioning
level generates auto_increment values, since if it was done
within a partition, it may fail to match the partition
function.

mysql-test/suite/parts/inc/partition_auto_increment.inc:
  Added tests
mysql-test/suite/parts/r/partition_auto_increment_blackhole.result:
  updated results
mysql-test/suite/parts/r/partition_auto_increment_innodb.result:
  updated results
mysql-test/suite/parts/r/partition_auto_increment_memory.result:
  updated results
mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
  updated results
sql/ha_partition.cc:
  In <engine>::write_row the auto_inc value is generated
  through handler::update_auto_increment (which calls <engine>::get_auto_increment() if needed).
  If:
  * INSERT_ID was set to 0
  * it was updated to 0 by 'INSERT ... ON DUPLICATE KEY UPDATE' and changed partitions for the row
  Then it would try to generate a auto_increment value in the
  <engine for a specific partition>::write_row, which will
  trigger the assert.
  
  So the solution is to prevent this by,
  in ha_partition::write_row set auto_inc_field_not_null and
  add MODE_NO_AUTO_VALUE_ON_ZERO
  in ha_partition::update_row (when changing partition) temporary
  set table->next_number_field to NULL which calling the
  partitions ::write_row().