Item_func_dyncol_create::print_arguments() printed only CHARSET clause
without COLLATE.

Therefore,

HEX(column_create(1,'1212' AS CHAR CHARACTER SET utf8mb3 COLLATE utf8mb3_bin))

inside a VIEW changed to just:

HEX(column_create(1,'1212' AS CHAR CHARACTER SET utf8mb3))

which changed the collation ID seen in the HEX output.

Note, the collation ID inside column_create() is not really much important.
(It's only important what the character set is).
And for COLLATE, the more important thing is what's later written
in the AS clause of COLUMN_GET:

SELECT
   COLUMN_GET(
    column_create(1,'1212' AS CHAR CHARACTER SET utf8mb3 COLLATE utf8mb3_bin)
    column_nr AS type  -- this type is more important
   );

Still, let's add the COLLATE clause into the COLUMN_CREATE() print output,
although it's not important for now for anything else than just the HEX output.
At least to make VIEW work in a more predictable way with HEX(COLUMN_CREATE()).

Also, in the future we can start using somehow the collation ID written inside
COLUMN_CREATE(), for example by making the `AS type` clause optional in
COLUMN_GET():
  COLUMN_GET(dyncol_blob, column_nr [AS type]);
instead of:
  COLUMN_GET(dyncol_blob, column_nr AS type);

SQL Server compatibility layer may need this for
the SQL_Variant data type support.