This straightens up some more inconsistencies in the integer
types in ft2font_wrapper.cpp and ft2font.cpp. Referring to the
Freetype 2 API guide:

https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html

1) FT_Get_Kerning's integer arguments are FT_UInt (unsigned int)
but we were passing it signed ints.

2) FT_Load_Glyph's flags argument is an FT_Int32 (signed int...
usually, see footnote) but our set_text and load_glyph were
using FT_UInt32, and converting Python values to unsigned int.

3) FT_Load_Char's flags argument is an FT_Int32 (signed int...
usually, see footnote) but our load_char was using FT_UInt32,
and converting Python values to unsigned int.

4) load_char in ft2font_wrapper declared charcode as a signed
long (and load_char in ft2font does indeed expect a signed long
from the wrapper, though it then turns it into an unsigned
long, I don't know why this is set up that way), but was
converting the Python value to an unsigned long (k) not a
signed long (l).

5) get_glyph_name in ft2font_wrapper declared glyph_number as
unsigned int, and indeed ft2font is expecting an unsigned int
(Freetype is expecting an FT_UInt, which is the same thing),
but it was converting the Python value to a signed int (i)
not an unsigned int (I).

Footnote: the FT_Int32 and FT_UInt32 types that we have to use
for some values are defined as being the signed and unsigned
variants of whichever integer type is *exactly* 32 bits in
size. Freetype defines them as int if it's 32 bits, otherwise
long if *that's* 32 bits, otherwise it gives up and errors out.
However, we simply assume they're always ints, which isn't
technically correct. We could probably fix this with a bit of
`sizeof()` use, but I'm not sure if we want to bother, because
it's almost certainly the case that the int types are 32 bits
in size on all platforms matplotlib is targeting - if there are
still any significant platforms where int is 16 bits and so these
wind up as long, I'd be surprised. I thought it was worth noting,
though.