Engine: Unescape \[ before calculating wrapped text width

I found some more buggy behaviour that AGS exhibits when splitting lines with "\\[" in them. It measures the width *before* removing the \\ symbol from the string. If "\\[" is repeated enough in a displayed string, the resulting wrapping point can be very far off. I wrote a test case to demonstrate (by replacing cEgo_Look in the AGS default project):

```
function cEgo_Look()
{
	DrawingSurface *s;

	s = Room.GetDrawingSurfaceForBackground();
	s.DrawingColor = 1;
	s.DrawRectangle(10, 30, 110, 70);
	s.DrawingColor = 15;
	s.DrawStringWrapped(10, 30, 100, eFontNormal, eAlignLeft, "This is 40 ] symbols in 100px.[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]");
	s.DrawingColor = 1;
	s.DrawRectangle(10, 80, 110, 120);
	s.DrawingColor = 15;
	s.DrawStringWrapped(10, 80, 100, eFontNormal, eAlignLeft, "This is 40 \[ symbols in 100px.[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[\[");
	s.DrawingColor = 15;
	s.DrawStringWrapped(180, 30, 140, eFontNormal, eAlignLeft, "Raw text:[.egaugnal tfel-ot-thgir a erew ti fi ekil kool dluow hsilgnE tahw si sihT");
	SetGameOption(28, 1);
	s.DrawingColor = 15;
	s.DrawStringWrapped(180, 130, 100, eFontNormal, eAlignRight, ".egaugnal tfel-ot-thgir a erew ti fi ekil kool dluow hsilgnE tahw si sihT");
	SetGameOption(28, 0);
	s.Release();

	return;
}
```

Here's the output from 3.3.0 compared with the output from 3.3.1 alpha 2 including this patch:

http://i.imgur.com/LXqnxCG.png

In the blue rectangles, you can see comparisons between a wrapped 100px section of ] symbols and a wrapped 100px section of \\[ symbols. 3.3.0 appears to wrap the text at about halfway and includes a trailing \\ on each line. This is because it's counting each [ as a \\[ and so widening the text (\\[\\[\\[\\[\\[...).

My patch corrects this problem, but it also refactors the AGS right-to-left text rendering support. CJ had a separate function called split_lines_rightleft. He was reversing the text, then stepping backwards through it with a divergent algorithm that did not, for instance, include "..." if it ran out of lines. I modified the code so that the reversal happens as the last step, allowing both directions of text to be split with the same algorithm and achieving the same result as 3.3.0. You can verify this with the display on the right-hand side of each screenshot in the image above ^^.

I also removed an unused function that referenced some right-to-left stuff called "wouttext_reverseifnecessary". This might have been left over from CJ's early attempts at RTL support.