Split Item_temporal_func::fix_length_and_dec()

We're anticipating the following additions and changes soon:

• MDEV-12513 INTERVAL data type
• MDEV-10018 Timestamp with time zone
• Hybrid functions like COALESCE will be able to return values of the new data types (including INTERVAL and TIMESTAMP WITH TIME ZONE, so the Item API will be extended with some new method to fetch native representations of these data types:

  virtual bool get_value(Value *value);

  where Value will be a new class, most likely based on struct st_value.

• Functions CONVERT_TZ() and TIMEDIFF() will support TIMESTAMP WITH TIME ZONE, so they will become hybrid type functions rather than fixed type functions.
• The function STR_TO_DATE will be extended to detect time zone formats and set its return type to TIMESTAMP WITH TIME ZONE when applicable.

The intent of this task is to make item_timefunc.h and item_timefunc.cc more ready for the mentioned tasks. This task will include the following changes:

1. The key point is to get rid of the generic Item_temporal_func::fix_length_and_dec and particular of this code:

uint char_length= mysql_temporal_int_part_length(field_type());

which is not friendly to adding new data types.

• The code related to calculating the length of the integer part will migrate to fix_length_and_dec() implementations of individual Item_temporal_func descendants.
• The code related to calculating "decimals" will migrate as a new method Type_str_attributes.

2. The classes Item_date_add_interval, Item_func_add_time, Item_func_str_to_date (implementing temporal hybrid functions DATE_ADD(), ADD_TIME(), STR_TO_DATE()) will become descendants of Item_hybrid_func, so later we can add support for the INTERVAL and TIMESTAMP WITH TIME ZONE data types easier, e.g. reuse the get_value() related infrastructure. In order to do this we'll derive Item_temporal_hybrid_func from Item_hybrid_func rather than Item_temporal_func.

Note, in the current implementation, Item_temporal_hybrid_func descendants use the inherited method Item_temporal_func::save_in_field() which uses save_date_in_field() even if the return data type is VARCHAR. This is wrong. See MDEV-12515. When we move Item_temporal_hybrid_func to Item_hybrid_func, this bug should automatically be gone, as this change will make Item_temporal_hybrid_func use the inherited method Item_hybrid_func::save_in_field() instead, which handles all data types (including VARCHAR) more precisely.

3. The function mysql_temporal_int_part_length() will be removed.

4. Expressions of the GEOMETRY type (and its variants such as POINT) will be disallowed as arguments to DATE_ADD(), ADDTIME() and STR_TO_DATE(). This will be a similar change to those that we earlier did for other hybrid functions (e.g. in MDEV-12238, MDEV-11478). Note, we however won't add these members to Type_handler_data at this point:

Type_aggregator m_type_aggregator_for_date_add;

Type_aggregator m_type_aggregator_for_addtime;

Type_aggregator m_type_aggregator_for_str_to_date;

They we'll be added later, when new reasonable data type pairs appear. For now we'll just return an error for all non-traditional types (with GEOMETRY being the only one non-traditional type at this point).