Fixed such that we fail if using integer constants for character set fields, now need to have correct constant types

Fixed so that character set constants are encoded as hex strings in frm file, but as utf8 strings in the same manner as default values in show create table and information schema tables

Backport for 5.5

In non debug builds, the statements:
- SHOW PROCEDURE CODE
- SHOW FUNCTION CODE
used to fail with a "syntax error", which is misleading.

These statements have been changed to return the following error for non
debug builds:
ERROR HY000: The 'SHOW PROCEDURE|FUNCTION CODE' feature is disabled; you
need MySQL built with '--with-debug' to have it working

For debug builds (./configure --with-debug), nothing is changed.

Backport for 5.5

Backport to 5.5

BUG#48397, set key_part->length to key_part->store_length isn't correct, store_length is a bit longer

per-file comments:
  mysql-test/r/mysql_upgrade.result
     result updated
  mysql-test/t/mysql_upgrade.test
     --skip-verbose option added to the call

Fixed code review change to ensure that VALUES constants are of the same result type as the field they are constants for

Item_sum::set_aggregator() may be called multiple times during query preparation.
On subsequent calls: verify that the aggregator type is the same,
and re-use the existing Aggregator.


sql/item_sum.cc:
  In Item_sum::set_aggregator(): re-use existing Aggregator if already set.
  
  Remove some friend declarations, add some accessor functions.
  Cleanup some DBUG_ENTER and DBUG_RETURN code.
sql/item_sum.h:
  Make some member fields private, add accessors instead.
  Remove some un-necessary friend declarations.
  Remove some default arguments from constructors.
sql/opt_sum.cc:
  Use accessor functions in Item_sum.
sql/sql_select.cc:
  Fix mis-spelled DBUG_ENTER text.
  Use accessor functions in Item_sum.
sql/sql_yacc.yy:
  Use explicit true/false rather than default arguments when constructing
  Item_sum_xxx objects.

   (backport)
   mysql_upgrade script accepts --upgrade-system-tables option,
   fixing only system tables in this case.

per-file comments:
  client/mysql_upgrade.c
WL#4991 mysql_upgrade --fix-privilege-tables
    --upgrade-system-tables option added.
   if it is set, the tool won't look for the mysqlcheck then
   run_mysqlcheck_fixnames() and run_mysqlcheck_upgrade won't be called.
  mysql-test/r/mysql_upgrade.result
WL#4991 mysql_upgrade --fix-privilege-tables
    test result added
  mysql-test/t/mysql_upgrade.test
WL#4991 mysql_upgrade --fix-privilege-tables
    test case added

BUG#48165, needed to introduce length restrictions on partitioning fields to ensure that no stack overruns occur

Fixed sql_mode issue in BUG#48164, will ignore sql_mode when generating constants, also warnings will not be tolerated

Disabled execution of this test for embedded server until fix for
bug 41971 'Thread state on embedded server is always "Writing to net"'
is back-ported to this tree.

Fixing locale name: en_US.UTF-8 -> en_US.utf8

Concurrent execution of statements which require non-table-level
write locks on several instances of the same table (such as
SELECT ... FOR UPDATE which uses same InnoDB table twice or a DML
statement which invokes trigger which tries to update same InnoDB
table directly and through stored function) and statements which
required table-level locks on this table (e.g. LOCK TABLE ... WRITE,
ALTER TABLE, ...) might have resulted in a deadlock.

The problem occured when a thread tried to acquire write lock
(TL_WRITE_ALLOW_WRITE) on the table but had to wait since there was
a pending write lock (TL_WRITE, TL_WRITE_ALLOW_READ) on this table
and we failed to detect that this thread already had another instance
of write lock on it (so in fact we were trying to acquire recursive
lock) because there was also another thread holding write lock on the
table (also TL_WRITE_ALLOW_WRITE). When the latter thread released
its lock neither the first thread nor the thread trying to acquire
TL_WRITE/TL_WRITE_ALLOW_READ were woken up (as table was still write
locked by the first thread) so we ended up with a deadlock.

This patch solves this problem by ensuring that thread which
already has write lock on the table won't wait when it tries
to acquire second write lock on the same table.

mysql-test/r/lock_sync.result:
  Added test case for bug #45143 "All connections hang on concurrent
  ALTER TABLE".
mysql-test/t/lock_sync.test:
  Added test case for bug #45143 "All connections hang on concurrent
  ALTER TABLE".
mysys/thr_lock.c:
  Ensured that thread can acquire write lock on the table without
  waiting if it already has write lock on it even if there are other
  threads holding write locks on this table (this is normal situation
  for, e.g., TL_WRITE_ALLOW_WRITE type of lock).
  
  Adjusted comments to better explain why it is OK to do so and added
  asserts to prevent introduction of scenarios in which this can cause
  problems.

The problem here is that the latest innodb push contains
both MYSQL_STORAGE_ENGINE(INNOBASE) and MYSQL_STORAGE_ENGINE(INNOBASE)
in the same CMakeLists.txt, to make the resulting library
ha_innodb.dll, instead of ha_innobase.dll.

Using multiple MYSQL_STORAGE_ENGINE within the same  CMakeLists.txt
conflicts with the fix for the bug Bug #47795 "CMake, storage engine
name different from directory name". Top-level CMakeLists.txt now 
parses storage engine's  CMakeLists.txt to extract engines name from 
MYSQL_STORAGE_ENGINE().

For innodb, it concludes that there is not storage engine named
INNOBASE, hence WITH_INNOBASE_STORAGE_ENGINE has no effect.

The fix is to use SET_TARGET_PROPERTIES(... PROPERTIES OUTPUT_NAME ...),
instead of renaming the engine to have plugins named ha_innodb.dll.