MDEV-29070 SIGSEGV in my_decimal::operator= and Assertion `0' failed and in Item_type_holder::val_decimal on SELECT

The bug is fixed by the patch ported from MySQL. See the comprehensive
description below.

commit 455c4e8810c76430719b1a08a63ca0f69f44678a
Author: Guilhem Bichot <guilhem.bichot@oracle.com>
Date:   Fri Mar 13 17:51:27 2015 +0100

    Bug#17668844: CRASH/ASSERT AT ITEM_TYPE_HOLDER::VAL_STR IN ITEM.C

    We have a predicate of the form:
    literal_row <=> (a UNION)

    The subquery is constant, so Item_cache objects are used for its
    SELECT list.
    In order, this happens:
    - Item_subselect::fix_fields() calls select_lex_unit::prepare,
    where we create Item_type_holder's
    (appended to unit->types list), create the tmp table (using type info
    found in unit->types), and call fill_item_list() to put the
    Item_field's of this table into unit->item_list.
    - Item_subselect::fix_length_and_dec() calls set_row() which
    makes Item_cache's of the subquery wrap the Item_type_holder's
    - When/if a first result row is found for the subquery,
    Item_cache's are re-pointed to unit->item_list
    (i.e. Item_field objects which reference the UNION's tmp table
    columns) (see call to Item_singlerow_subselect::store()).
    - In our subquery, no result row is found, so the Item_cache's
    still wrap Item_type_holder's; evaluating '<=>' reads the
    value of those, but Item_type_holder objects are not expected to be
    evaluated.

    Fix: instead of putting unit->types into Item_cache, and later
    replacing with unit->item_list, put unit->item_list in Item_cache from
    the start.

Approved by Oleksandr Byelkin <sanja@mariadb.com>