gets deadlocked when dropping w/ log on"

Log tables rely on concurrent insert machinery to add data.
This means that log tables are always opened and locked by
special (artificial) logger threads. Because of this, the thread
which tries to drop a log table starts to wait for the table
to be unlocked. Which will happen only if the log table is disabled.
Alike situation happens if one tries to alter a log table.
However in addition to the problem above, alter table calls
check_if_locking_is_allowed() routine for the engine. The
routine does not allow alter for the log tables. So, alter
doesn't start waiting forever for logs to be disabled, but 
returns with an error.
Another problem is that not all engines could be used for
the log tables. That's because they need concurrent insert.

In this patch we:
(1) Explicitly disallow to drop/alter a log table if it
    is currently used by the logger.
(2) Update MyISAM to support log tables
(3) Allow to drop log tables/alter log tables if log is
    disabled
At the same time we (4) Disallow to alter log tables to
unsupported engine (after this patch CSV and MyISAM are 
alowed)
Recommit with review fixes.

catch that.
Stale CMakeLists.txt

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge-5.0

into  mysql.com:/home/psergey/mysql-5.1-merge-2

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge-5.0

into  trift2.:/M51/merge-5.1

into  trift2.:/M51/merge-5.1

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge-5.0

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge

into  dl145k.mysql.com:/data0/mkindahl/bk/mysql-5.1-new-rpl

into  dl145k.mysql.com:/data0/mkindahl/bk/mysql-5.1-new-rpl

into  trift2.:/M51/merge-5.1

into  trift2.:/M51/merge-5.1

into  dl145k.mysql.com:/data0/mkindahl/bk/MERGE/mysql-5.1-merge

into  chilla.local:/home/mydev/mysql-5.1-amerge

into  dl145k.mysql.com:/data0/mkindahl/bk/MERGE/mysql-5.0-merge

into  zippy.(none):/home/cmiller/work/mysql/merge/mysql-5.1

into  andrepl.(none):/home/elkin/MySQL/TEAM/FIXES/5.1/20919_temp_nlog

We now reset the THD members related to auto_increment+binlog in
MYSQL_LOG::write(). This is better than in THD::cleanup_after_query(),
which was not able to distinguish between SELECT myfunc1(),myfunc2()
and INSERT INTO t SELECT myfunc1(),myfunc2() from a binlogging point
of view.
Rows_log_event::exec_event() now calls lex_start() instead of
mysql_init_query() because the latter now does too much (it resets
the binlog format).

into  andrepl.(none):/home/elkin/MySQL/TEAM/FIXES/5.1/20919_temp_nlog

into  gbichot3.local:/home/mysql_src/mysql-5.0

into  orca.ndb.mysql.com:/space_old/pekka/ndb/version/my51-bug18781

into  orca.ndb.mysql.com:/space_old/pekka/ndb/version/my51-bug18781

into  gbichot3.local:/home/mysql_src/mysql-5.1

into  romeo.(none):/home/bk/b20821-mysql-5.1-new-rpl

into  chilla.local:/home/mydev/mysql-5.1-aid

into  dsl-hkigw8-feb1fb00-100.dhcp.inet.fi:/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/5.0/20919_temp_nlog

set properly.

closing temp tables through end_thread
had a flaw in binlog-off branch of close_temporary_tables where
next table to close was reset via table->next
 for (table= thd->temporary_tables; table; table= table->next)
which was wrong since the current table instance got destoyed at
	close_temporary(table, 1);

The fix adapts binlog-on branch method to engage the loop's internal 'next' variable which holds table->next prior table's destoying.

into  gbichot3.local:/home/mysql_src/mysql-5.1

into  gbichot3.local:/home/mysql_src/mysql-5.1