This patch contains fixes for two problems:

1. As originally reported, the server crashed on Mac OS X when trying to access
   an EXAMPLE table after the EXAMPLE plugin was installed.

   It turned out that the dynamically loaded EXAMPLE plugin called the
   function hash_earch() from a Mac OS X system library, instead of
   hash_earch() from MySQL's mysys library. Makefile.am in storage/example
   does not include libmysys. So the Mac OS X linker arranged the hash_search()
   function to be linked to the system library when the shared object is
   loaded.

   One possible solution would be to include libmysys into the linkage of
   dynamic plugins. But then we must have a libmysys.so, which must be
   used by the server too. This could have a minimal performance impact,
   but foremost the change seems to bee too risky at the current state of
   MySQL 5.1.

   The selected solution is to rename MySQL's hash_search() to my_hash_search()
   like it has been done before with hash_insert() and hash_reset().

   Since this is the third time, we need to rename a hash_*() function,
   I did renamed all hash_*() functions to my_hash_*().

   To avoid changing a zillion calls to these functions, and announcing
   this to hundreds of developers, I added defines that map the old names
   to the new names.

   This change is in hash.h and hash.c.

2. The other problem was improper implementation of the handlerton-to-plugin
   mapping. We use a fixed-size array to hold a plugin reference for each
   handlerton. On every install of a handler plugin, we allocated a new slot
   of the array. On uninstall we did not free it. After some uninstall/install
   cycles the array overflowed. We did not check for overflow.

   One fix is to check for overflow to stop the crashes.

   Another fix is to free the array slot at uninstall and search for a free slot
   at plugin install.

   This change is in handler.cc.

Repush of change to fix tests on Pushbuild.

Link with mtmalloc on Solaris as it is done in our release builds.
Replace deprecated flag with the newer option as already done in
other scripts.

Server created "arc" directories inside database directories and
maintained there useless copies of .frm files.

Creation and renaming procedures of those copies as well as
creation of "arc" directories has been discontinued.
Removal procedure has been kept untouched to be able to
cleanup existent database directories by the DROP DATABASE
query. Also view renaming procedure has been updated to remove
these directories.

     JOIN for the subselect wasn't cleaned if we came upon an error
     during sub_select() execution. That leads to the assertion failure
     in close_thread_tables()

     part of the 6.0 code backported

per-file comments:
  mysql-test/r/sp-error.result
Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
    test result

  mysql-test/t/sp-error.test
Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
    test case

  sql/sp_head.cc
Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
    lex->unit.cleanup() call added if not substatement

Bug#38311 - Fix of some cruft from remove_files in ndb_autodiscover.test, clean up of distinct.test,
and replacing error numbers with error names.

Trimmed some error-prone and variable portions of the test and added 'flush status' to ensure deterministic test

            
A stored procedure involving substrings could crash the server on certain
platforms because of invalid memory reads.
          
During storing the new blob-field value, the cached value's address range
overlapped that of the new field value. This caused problems when the 
cached value storage was reallocated to provide access for a new 
characater set representation. The patch checks the address ranges, and if
they overlap, the new field value is copied to a new storage before it is
converted to the new character set.

Substituted use of MTR's remove_file function in the tests
Started with 5.0 tree and will clean up any offenders discovered during upmerge.

no conflicts, no real code changes

no conflicts

Bug#37114: sql_mode NO_BACKSLASH_ESCAPES does not work properly with LOAD DATA      Bug#37114: sql_mode NO_BACKSLASH_ESCAPES does not work properly with LOAD DATA INFILE

tweaked test to make embedded server happy

It is a very big test and as such it takes a lot of time.

Solution is to divide the test in two parts, one for testing increasing
column size and one for decreasing size.

The innodb branch does extended tests (that myisam is not) due to the
$do_pk_tests variabel, that is the reason why the innodb branch takes
longer.

No increase of memory usage in innodb was found when analyzing, (tested
with looping some millions time of create/drop and alter commands)

The memory exhaust discovered in the test is due to mysqltest which
stores the result in memory (result-file) and this was the biggest
result file in the test framework, so by dividing the test into two
parts also cuts the memory usage of mysqltest.

NO_BACKSLASH_ESCAPES was not heeded in LOAD DATA INFILE
and SELECT INTO OUTFILE.  It is now.

Details:
- backport of some improvements which prevent sporadic
  failures from 5.1 to 5.0
- @@GLOBAL.CONCURRENT_INSERT= 0 also for slave server
- --sorted_result before all selects which have result
  sets with more than one row
- Replace error numbers by error names

                  
Fix the write_record function to record auto increment
values in a consistent way.