FROM_BASE64 was observed to have the wrong maximum length when its
argument was a CAST to UNSIGNED whose input was a negative number. The
reason was that CAST to UNSIGNED didn't take overflow into account and
returned a too low maximum length in some cases when its argument was
negative.

Fixed by changing how the maximum length for CAST to UNSIGNED and CAST
to SIGNED is determined.

Item_typecast_unsigned:

Since a cast from a small negative integer to UNSIGNED results in a
large positive integer, don't attempt to guess the maximum length from
the maximum length of the argument. Instead, use the maximum length
for the returned data type, which is already set in the constructor.

Item_typecast_signed:

Casts from a large unsigned integer to SIGNED could overflow, and
return an equally large negative number. Item_typecast_signed didn't
take into account that the negative number needed one extra character
for the sign. Now, account for the sign in max_length. This also makes
it possible to reuse the default implementation of decimal_precision()
from Item, so Item_typecast_signed::decimal_precision() is removed.

Asserts are added in the val_int() functions of both
Item_typecast_unsigned and Item_typecast_signed to verify that the
returned value does not exceed the maximum width stated by the
metadata.

The asserts revealed one more problem, which is fixed by the patch:

Item_hex_string's decimal_precision() and decimal_int_part() functions
return the number of bytes needed to store the value, not the number
of decimal digits needed. Fixed by making decimal_precision() convert
the byte length to decimal digits.

Change-Id: I5cb9d9b563218bc252a87a6e5a50be3e94e06529