This is related to ebfa320956169e3419234b72fee51bd596867661, but
when reading the hash chain entry length, not writing it.

If char is signed, then before this change the length would be
negative, causing problems loading the dictionary.

The length is stored as the first byte in the output from
compile_line. As the data pointer is char, if char is signed then
length could be negative resulting in undefined behaviour. This
commit fixes the issue by reading and writing that byte as a
uint8_t.

This bug was caused by 2a00ca79f6.
Previously, the entries could only be a maximum of 128 bytes, and
would not be negative on platforms with signed chars. That
commit was made to support long emoji entries, especially for
non-Latin languages where the utf-8 representations could be
longer than 128 bytes.

This change also adds some documentation to make it clearer what
is going on. NOTE: The code should really be using actual struct
objects instead of writing to opaque char buffers.

Reported by Reef Turner <[email protected]>

Reported by Reef Turner <[email protected]>

This fixes the clang warning:

    comparison of unsigned expression < 0 is always false
    [-Wtautological-compare]

Reported by Reef Turner <[email protected]>

See ar_listx as an example.

This is not used by any of the espeak-ng voices and languages.
Additionally, this functionality would be superceded by support
for specifying the language used by different scripts in the
language argument on the command line.

reduced length to 160 for unstressed syllables

Added some exceptions to the italian dictionaries