Fixed text rendering issue with spans.

Bug 6598784

The algorithm uses three imbricated loops:
- paragraphs
- span regions (called "blocks" in that description) in these
- characters in these

We can ignore the paragraphs and assume paraStart==0.

The span region loop cuts the text into blocks of text which share
the same set of MetricAffectingSpan spans applied to them. Note that
spanStart and spanEnd represent such a range, and not necessarily an
actual span range.

The third loop then iterates over the characters of these blocks, and creates
a new line (calling out() as soon as the width has been reached.

The core of the problem comes from the 'nextSpanStart' variable.
It is used to restart the block loop from a previous position in case
a line has been created that does not intersect with the current block.

However, in case the current block is larger than the width of the text,
the character loop is going to create other lines of text before we exit the
j-loop. Going back to the block loop, we reset spanStart to the nextSpanStart,
which may be too far back in the text. As a result, the same range of characters
is measured again.

The (spanStart == spanEnd) test was used to handle the case where
nextSpanStart was indeed assigned to a value different than spanEnd.

This fix simplifies this logic and removes the nextSpanStart variable:

When the created line ends before the current block (here < spanStart), we
immediately exit the character loop, re-starting the block loop from the
current position.

Patch 4: added a fix in measured to handle overlapping character ranges.

Change-Id: Ie71b3cf4018b332e335ea916fef08acb43a6679e