Transition from tinyxml to tinyxml2 and improved font rendering.

1) Rewritten XmlReader using tinyxml2 - now it's using less memory. Profit is some about 15 Mb immediately after loading case1.

2) Improved font rendering. Here is two screenshots to compare. For font render added better outlining, utf-8 support and better scaling, so it looks much better in fullscreen now.
Before:
![scr before](https://cloud.githubusercontent.com/assets/8434495/3906022/dcb10034-22ee-11e4-9b78-da73f3f419e9.png)
After:
![scr after](https://cloud.githubusercontent.com/assets/8434495/3906034/f5c0ad54-22ee-11e4-82a1-b1d3a9790013.png)

Also here is utf8 example, though complete translation support need much more changes:
![utf8 example](https://cloud.githubusercontent.com/assets/8434495/3906137/13a8d6b0-22f0-11e4-8aec-85b9f67a9323.png)

Interesting idea, but I would be curious to know what the memory footprint of a language like Chinese would be with respect to the whole.  Given that we're talking about relatively small glyphs, even if we had a language with tens of thousands of glyphs to be rendered, I'm personally at least initially dubious of the idea that it would significantly add to the memory footprint of the game.  I worry that doing things this way could cause lower-end computers to see initial slowdowns when we first need to start rendering glyphs to textures.

It's entirely possible that I'm wrong, that there'd be no perceptible slowdown, and that the memory footprint of languages with many glyphs would be significant.  However, I would be curious to see numbers.  Given the additional complexities involved as well with having dynamically allocated glyphs, it seems to me that we should at least try the more naive approach and only optimize if need be.  Optimizing something that may not even need optimizing can be the cause of many troubles in programming.