Some of the metadata of the TO_DAYS function is incorrect. It reports
that max_char_length() is 6, decimal_precision() is 5 and
decimal_int_part() is 5. All of these should have been 7, because
TO_DAYS('9999-12-31') returns 3652424, which is seven digits wide.
This could lead to "data out of range" errors.

Correcting max_char_length() can be done by changing resolve_type() to
call fix_char_length() with the correct length (7 instead of 6). But
when max_char_length() is corrected to return 7, decimal_precision()
and decimal_int_part() return 6 instead of 5, which is still one off.
This is because Item::decimal_precision() takes max_char_length() and
subtracts one if the Item is signed, because it assumes the
max_char_length() includes space for the sign. Item_func_to_days never
returns negative values, so it doesn't need space for the sign, even
though its return type is a signed type.

Making TO_DAYS unsigned is not an option, because it breaks
calculations such as TO_DAYS(col1)-TO_DAYS(col2), which will start
raising "out of range" errors if TO_DAYS(col1) is less than
TO_DAYS(col2). (Since the result of subtracting an unsigned integer
from another unsigned integer is also unsigned, and hence negative
results are out of range.) The patch instead increases the maximum
character length to 8, so that decimal_precision() also returns a
large enough value.

Change-Id: Ie0254cef5c84cb0341542c2804ee84b8f85cfc1a