This should hopefully address the long-reported "Too many open files"
error message (Fix matplotlib#3315).

To reproduce: On a Mac or Windows box with starvation for file
handles (Linux has a much higher file handle limit by default), build
the docs, then immediately build again.  This will trigger the caching
bug.

The font cache in the mathtext renderer was broken.  It was caching a
font file once for every *combination* of font properties, including
things like size.  Therefore, in a complex math expression containing
many different sizes of the same font, the font file was opened once for
each of those sizes.

Font files are opened and kept open (rather than opened, read,
and closed) so that FreeType only needs to load the actual glyphs that
are used, rather than the entire font.  In an era of cheap memory and
fast disk, it probably doesn't matter for our current fonts, but once
 matplotlib#5214 is merged, we will have larger font files with many more glyphs
and this loading time will matter more.

The solution here is to do all font file loading in one place and to use
`lru_cache` (available since Python 3.2) to do the caching, and to use
only the file name and hinting parameters as a cache key.  For earlier
versions of Python, the functools32 backport package is required.  (Or
we can discuss whether we want to vendor it).

mathtext creates Python dictionaries for the charmap and inverse charmap
for each font.  This turns out to be unnecessary:

1) freetype has an API to do a charmap lookup that is faster than a
Python dictionary

2) The inverse charmap isn't really necessary if we convert the
latex_to_bakoma to use unicode character points rather than glyph
indices.

This should have a large impact when matplotlib#5241 is merged with larger fonts.