Step#1 MDEV-27896 Wrong result upon `COLLATE latin1_bin CHARACTER SET latin1` on the table or the database level

- Adding data type aliases:
  using Lex_column_charset_collation_attrs_st = Lex_charset_collation_st;
  using Lex_column_charset_collation_attrs = Lex_charset_collation;

  and using them all around the code (except lex_charset.*)
  instead of the original names.

- Renaming Lex_field_type_st::lex_charset_collation()
  to charset_collation_attrs()

- Renaming Column_definition::set_lex_charset_collation()
  to set_charset_collation_attrs()

- Renaming Column_definition::lex_charset_collation()
  to charset_collation_attrs()

Rationale:

The name "Lex_charset_collation" was a not very good name.
It does not tell details about its properties:
1. if the charset is optional (yes)
2. if the collation is optional (yes)
3. if the charset can be exact (yes) or context (no)
4. if the collation can be: exact (yes) or context (yes)
5. if the clauses can be repeated multiple times (yes)

We'll need a few new data types soon with different properties.
For example, to fix MDEV-27896 and MDEV-27782, we'll need a new
data type which is very like Lex_charset_collation, but additionally
supports CHARACTER SET DEFAULT (which is allowed on table and database level,
but is not allowed on the column level yet), i.e. with:
  "the charset can be exact (yes) or context (yes)" in N3.

So we'll have to rename Lex_charset_collation to something else,
e.g.: Lex_exact_charset_extended_collation_attrs,
and add a new data type:
e.g. Lex_extended_charset_extended_collation_attrs

Also, we'll possibly allow CHARACTER SET DEFAULT at the column level for
consistency with other places. So the storge on the column level can change:
- from Lex_exact_charset_extended_collation_attrs
- to   Lex_extended_charset_extended_collation_attrs

Adding the aliases introduces a convenient abstraction against
upcoming renames and c++ data type changes.