Closes #396.

Prevents a segfault.

It is possible -- especially at higher speeds -- for the n at the
end of a word to be velarised if the next word starts with a velar
plosive. I prefer the velarised sound between word boundaries, but
others do not. As such, limit the velarisation to within the word
only.

[1]	https://en.wikipedia.org/wiki/English_phonology

This reverts commit d08b8e43ca.

This commit causes gcc-4.8 to output a different SHA1 hash on the
language-phonemes test for `af` (the first language tested). It
does not break on clang or on gcc-7 so may be a compiler bug,
however the Travis CI build server is using it on Ubuntu Trusty
(14.04 LTS) and so may other older OSes.

This is a fix for https://github.com/nvaccess/nvda/issues/7740.

With the addition of emoji support, dictionary entries can now be
longer than 128 bytes. This fix makes sure the character is
interpreted as an unsigned byte so it does not treat long entries
as having a negative offset.

Treating the offset as a signed byte (like in the previous code)
could cause the hash chain search to loop indefinitely when
processing certain input, like the Tamil characters in the NVDA
issue noted above that is added as a test case to translate.test.

It is set in voices.c but never used. docs/voices.md indicates that the keyword intonation only takes one parameter, confirming that option_tone2 is unused.

This is a similar change to b60d2452c3.
In this case, it is when tr->dictionary_name is passed as the name
parameter in LoadDictionary.

This happens in the SetTranslator2 function when loading the
dictionary for the second language translator object.