Bug#11764503 (Bug#57341) Query in EXPLAIN EXTENDED shows wrong characters

@ mysql-test/r/ctype_latin1.result
  @ mysql-test/r/ctype_utf8.result
  @ mysql-test/t/ctype_latin1.test
  @ mysql-test/t/ctype_utf8.test
  Adding tests

  @ sql/mysqld.h
  @ sql/item.cc
  @ sql/sql_parse.cc
  @ sql/sql_view.cc

  Refactoring (thanks to Guilhem for the idea):

  Item_string::print() was hard to understand because of the different
  QT_ constants: in "query_type==QT_x", QT_x is explicitely included
  but the other two QT_ are implicitely excluded. The combinations
  with '||' and '&&' make this even harder.
  - logic is now more "explicit" by changing QT_ constants to a bitmap of flags:
    QT_ORDINARY: no change,
    QT_IS -> QT_TO_SYSTEM_CHARSET | QT_WITHOUT_INTRODUCERS,
    QT_EXPLAIN -> QT_TO_SYSTEM_CHARSET
    (QT_EXPLAIN was introduced in the first version of the Bug#57341 patch)
  - Item_string::print() is rewritten using those flags

  Bugfix itself:

  When QT_TO_SYSTEM_CHARSET is used alone (with no QT_WITHOUT_INTRODUCERS),
  we print string literals as follows:

  - display introducers if they were in the original query
  - print ASCII characters as is
  - print non-ASCII characters using hex-escape
  Note: as "EXPLAIN" output is only for human readability purposes
  and does not need to be a pasrable SQL, so using hex-escape is Ok.
  ErrConvString class perfectly suites for hex escaping purposes.

sql/sql_parse.cc

@@ -4439,7 +4439,11 @@ static bool execute_sqlcom_select(THD *thd, TABLE_LIST *all_tables)
         char buff[1024];
         String str(buff,(uint32) sizeof(buff), system_charset_info);
         str.length(0);
-        thd->lex->unit.print(&str, QT_ORDINARY);
+        /*
+          The warnings system requires input in utf8, @see
+          mysqld_show_warnings().
+        */
+        thd->lex->unit.print(&str, QT_TO_SYSTEM_CHARSET);
         str.append('\0');
         push_warning(thd, MYSQL_ERROR::WARN_LEVEL_NOTE,
                      ER_YES, str.ptr());