with other alterations causes lost tables

Using RENAME clause combined with other clauses of ALTER TABLE led to
data loss (the data was there but not accessible). This could happen if the
changes do not change the table much. Adding and droppping of fields and
indices was safe. Renaming a column with MODIFY or CHANGE was unsafe operation,
if the actual column didn't change (changing from int to int, which is a noop)
  
Depending on the storage engine (SE) the behavior is different:
1)MyISAM/MEMORY - the ALTER TABLE statement completes
  without any error but next SELECT against the new table fails.
2)InnoDB (and every other transactional table) - The ALTER TABLE statement
  fails. There are the the following files in the db dir -
  `new_table_name.frm` and a temporary table's frm. If the SE is file
  based, then the data and index files will be present but with the old
  names. What happens is that for InnoDB the table is not renamed in the
  internal DDIC.

Fixed by adding additional call to mysql_rename_table() method, which should
not include FRM file rename, because it has been already done during file
names juggling.

into  shellback.(none):/home/msvensson/mysql/yassl_import/my51-yassl_import

into  shellback.(none):/home/msvensson/mysql/yassl_import/my51-yassl_import

into  mysql.com:/usr/home/ram/work/bug22229/my51-bug22229

into  shellback.(none):/home/msvensson/mysql/mysql-5.1-maint

into  mysql.com:/usr/home/ram/work/bug22229/my51-bug22229

  Update test result due to fix for bug 23883.

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint

into  mysql.com:/usr/home/ram/work/bug21587/my51-bug21587

into  mysql.com:/usr/home/ram/work/bug21587/my51-bug21587

into  shakedown.(none):/home/jpipes/dev/mysql-5.0-maint

into  shakedown.(none):/home/jpipes/dev/mysql-5.1-new-maint2

Don't link mysql_upgrade with mysys

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint

Problems (appear only under some circumstances): 
  1. we get a reference to a deleted table searching in the 
     thd->handler_tables_hash in the mysql_ha_read().

  2. DBUG_ASSERT(table->file->inited == handler::NONE); assert fails in the
     close_thread_table().

Fix: end open index scans and table scans and remove references to the 
tables from the handler tables hash. After this preparation it is safe 
to close the tables. The close can no longer fail on open index/table 
scans and the closed table will not be used again by handler functions.
                                 

into  polly.local:/home/kaa/src/maint/mysql-5.1-maint

into  polly.local:/home/kaa/src/maint/mysql-5.0-maint

into  polly.local:/tmp/maint/bug22077/my51-bug22077

into  ymer.(none):/usr/local/mysql/tmp/mysql-5.0-gca

into  ymer.(none):/usr/local/mysql/tmp/mysql-5.1-new-maint

into  ymer.(none):/usr/local/mysql/tmp/mysql-5.0-gca

traces in Valgrind (broken libc6-dbg).
Installing libc6-dbg on Debian will still provide proper bactraces, even
without setting LD_LIBRARY_PATH explicitly.

since that is where  the lang files etc are

Remove other warnings about unused variables

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint

And it's not an "opt"

 - Put 'my_getpagesize' in it's own .c file
 - Map the call 'my_getpagesize' directly to 'getpagesize' if it exists
 - Add default implementation for 'my_getpagesize' to be used if no platform
   specfic function exists