This should hopefully address the long-reported "Too many open files"error message (Fixmatplotlib#3315).To reproduce: On a Mac or Windows box with starvation for filehandles (Linux has a much higher file handle limit by default), buildthe docs, then immediately build again.  This will trigger the cachingbug.The font cache in the mathtext renderer was broken.  It was caching afont file once for every *combination* of font properties, includingthings like size.  Therefore, in a complex math expression containingmany different sizes of the same font, the font file was opened once foreach 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 thatare used, rather than the entire font.  In an era of cheap memory andfast disk, it probably doesn't matter for our current fonts, but oncematplotlib#5214 is merged, we will have larger font files with many more glyphsand 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 useonly the file name and hinting parameters as a cache key.  For earlierversions of Python, the functools32 backport package is required.  (Orwe can discuss whether we want to vendor it).

mathtext creates Python dictionaries for the charmap and inverse charmapfor each font.  This turns out to be unnecessary:1) freetype has an API to do a charmap lookup that is faster than aPython dictionary2) The inverse charmap isn't really necessary if we convert thelatex_to_bakoma to use unicode character points rather than glyphindices.This should have a large impact whenmatplotlib#5241 is merged with larger fonts.