Remove redundant code for drawing text strings that contain only ASCII

I don't feel too strongly about this, and I think this would could be contentious. But let me try to sell this idea...

We currently have separate functions for printing text strings that must contain only ASCII characters, as apposed to the code paths that can operate on strings that could contain a mixture of ASCII and multi-byte UTF-8 character sequences. There is added complexity in having two parallel sets of code to do the same thing, more work in maintenance, potential danger in using the wrong ones, and there does not appear to be a measurable performance difference.

If you consider this only casually, dealing with single-byte ASCII characters seems "easy", while multi-byte UTF-8 sequences seem "difficult". But note that ALL ASCII characters have a cleared high bit (so they are below the value 128), while every single part of a multi-byte UTF-8 sequence has that bit set - so every byte is over 128. This makes it extremely easy to check for simple lower latin characters mixed in with complex characters. And because our routines were written by smart people (not me), this means that ASCII takes an "early exit" from these routines, making them very fast.

Our ASCII-only text printing routines generally run like this:

• Point at string byte
• Is this < 128?
• If yes, we can now print this

But when an ASCII character goes through our UTF-8 routines it is like this:

• Point at string byte
• If this is less than 128 then sequence length is 1
• If sequence length is 1 we can now print this

So there just isn't a measurable performance difference once compiler optimization comes into play.

And this patch shows some of the potential pitfalls of having two sets of routines to do the same thing. You'll see that overlay drawing must store and pass around a flag just to keep track of which of the routines to use in the end. There is also assumption that with define WITH_INTERNATIONAL there wil only be ascii yet we allow the viewing of international text and input of complex language while the translation system is off and showing English in the UI. Even an assumption that is now true, that numbers are always ascii, might not be true in the future or in a fork since there are many different numeral systems in use today.