Split rpl_row_charset into:

  - rpl_row_utf16.
  - rpl_row_utf32.

This way these tests can run independently if server supports
either one of the charsets but not both.

Cleaned up rpl_row_utf32 which had a spurious instruction:
-- let $reset_slave_type_conversions= 0

In BUG#51787 we were using the wrong charset to print out the
data. We were using the field charset for the string that would
hold the information. This caused the assertion, because the
string length was not aligned with UTF32 bytes requirements for
storage.

We fix this by using &my_charset_latin1 in the string object
instead of the field->charset(). As a side-effect, we needed to
extend the show_sql_type interface so that it took the field
charset is now passed as a parameter, so that one is able to
calculate the correct field size.

In BUG#51716 we had issues with Field_string::pack and
Field_string::unpack. When packing, the length was incorrectly
calculated. When unpacking, the padding the string would be
padded with the wrong bytes (a few bytes less than it should).

We fix this by resorting to charset abstractions (functions) that
calculate the correct length when packing and pad correctly the
string when unpacking.

Before this fix, client tools (mysql_upgrade, mysqlcheck, mysqldump)
would try to process performance schema tables, leading to failures.

The fix is to align FIRST_PERFORMANCE_SCHEMA_VERSION to 5.5.3,
which is the version number of mysql-trunk where the
performance schema is first available.

Before this fix, the performance schema instrumentation
in mdl.h / mdl.cc was incomplete, causing:
- build warnings,
- no data collection for the performance schema

This fix:
- added instrumentation helpers for the new preferred
  reader read write lock, mysql_prlock_*
- implemented completely the performance schema
  instrumentation of mdl.h / mdl.cc

Set $glob_bindir, like $bindir in v2
Removed some obsolete IM code rather than changing it

Before this fix, mysql_upgrade would always drop and re create
the performance_schema database.
This in theory could destroy user data created using 5.1 or older versions.

With this fix, mysql_upgrade checks the content of the
performance_schema database before droping it.

Fix for BUG#51215 "log-error partially works with version 5.5": WL 4738 (reengineering of server variables)
had broken the 5.1 behaviour of --log-error: --log-error without argument sent to stderr instead of writing
to a file with an autogenerated name.

mysql-test/suite/sys_vars/t/log_error_func.test:
  test that error log is created and shown in SHOW VARIABLES.
  Interestingly the error log's path is apparently relative if --log-error=argument is used, but
  may be absolute or relative if --log-error(no argument) is used (because then the path is derived from
  that of pidfile_name, which can be absolute or relative, depending on if autogenerated or not).
mysql-test/suite/sys_vars/t/log_error_func2.test:
  test that error log is created and shown in SHOW VARIABLES
mysql-test/suite/sys_vars/t/log_error_func3.test:
  test that error log is empty in SHOW VARIABLES
sql/mysql_priv.h:
  id for option --log-error
sql/mysqld.cc:
  No --log-error means "write errors to stderr", whereas --log-error
  without argument means "write errors to a file". So we cannot use the default logic
  of class sys_var_charptr, which treats "option not used" the same as "option used
  without argument" and uses the same default for both. We need to catch "option used",
  in mysqld_get_one_option(), and then "without argument". Setting to "" makes sure
  that init_server_components() will create the log, with an autogenerated name.
sql/sys_vars.cc:
  need to give the option a numeric id so that we can catch it in mysqld_get_one_option()

The unit test pfs_instr-t:
- generates a very long (10,000) bytes file name
- calls find_or_create_file.

This leads to a buffer overflow in mysys in my_realpath(),
because my_realpath and mysys file APIs in general do not
test for input parameters: mysys assumes every file name
is less that FN_REFLEN in length.

Calling find_or_create_file with a very long file name is likely
to happen when instrumenting third party code that does not use mysys,
so this test is legitimate.

The fix is to make find_or_create_file in the performance schema
more robust in this case.

The root cause of the failure is that when
Bug#51447 performance schema evil twin files
was fixed, instrumented file names got normalized.

The pfs-t unit test depends on this file normalization,
but it was not updated.

This fix aligns pfs-t.cc lookup_file_by_name()
with the logic in pfs_instr.cc find_or_create_file().

and "README" (header part: "This is a release of MySQL ...")
from "trunk" to "next-mr".

by adding the header part "This is MySQL ...".

the license remains to be the GPL Version 2, June 1991

This is *no* change in contents, the differences are formatting only
and an address update of the FSF. It continues to be Version 2, June 1991.

Bug#51676 Server crashes on SELECT, ORDER BY on 'utf8mb4' column
An additional fix. We should use 0xFFFD as a weight for supplementary
characters, not the "weight for character U+FFFD".

Using latin1 client character set for ASCII locales:
- because ascii is not a build-in character set
- for better backward compatibility

Bug#51675 Server crashes on inserting 4 byte char. after ALTER TABLE to 'utf8mb4' 
Bug#51676 Server crashes on SELECT, ORDER BY on 'utf8mb4' column


include/m_ctype.h:
  Defining MY_CS_REPLACEMENT_CHARACTER
mysql-test/r/ctype_utf8mb4.result:
  Adding tests
mysql-test/t/ctype_utf8mb4.test:
  Adding tests
strings/ctype-uca.c:
  Don't use UCA data for characters higher than 0xFFFF.
strings/ctype-ucs2.c:
  Using newly defined MY_CS_REPLACEMENT_CHARACTER
strings/ctype-utf8.c:
  Using newly defined MY_CS_REPLACEMENT_CHARACTER
  Removing unesed variable "plane".