Replace unifont interface with CFontManager

[historic_bruno]

Font textures and associated data are currently handled by unifont, which is a low-level C style wrapper around the h_mgr system. It would be better if we had a CFontManager instead to abstract this and provide a central point for loading and reloading fonts (useful for fixing #741). It would mirror other managers we have like CTextureManager and CShaderManager. gDEBugger also indicates we're leaking font textures, maybe implementing this would provide a better means of cleaning them up?

[Philip]

Possibly relevant recent change: all the code that rendered text with unifont has now been changed to use the new CTextRenderer, which provides a more appropriate level of abstraction. Some still uses CFont directly to get text metrics (line spacing, character width, etc) - it'd probably be best to expose that data via CTextRenderer somehow, so nothing else needs to use CFont.

Then I think it'd probably be best to delete CFont and unifont, create a new CFont that contains the old unifont file-loading functionality directly (and then it can use CTextureManager instead of raw ogl_tex, for improved consistency and compression support etc), and create a new CFontManager that is a simple global cache of CFonts (probably accessed by CTextRenderer as g_Renderer.GetFontManager()).