bug#56682: Fix the long lines font locking related slowdowns

[Gregory Heytings <gregory@heytings.org>]

I pushed another improvement to the branch.  Now motion in a font-locked 
buffer is almost as fast as in a non font-locked one; I don't think it's 
possible to make further significant improvements.

It turns out that the motion slowdowns in font locked-buffers were caused 
only indirectly by font locking.  What happens is that in a font-locked 
buffer, get_next_display_element calls next_element_from_buffer which uses 
handle_stop (and therefore compute_stop_pos) to position the iterator on 
the next element.  In a file such as long-line.xml, there are many more 
stop positions when the buffer is font locked, roughly 100 times more. 
The solution is to make back_to_previous_visible_line_start do something 
closer to what it promises, namely "Set IT's current position to the 
previous visible line start."  Previously it moved IT to the beginning of 
the (temporarily narrowed) buffer, which was already much better than 
moving it to the beginning of the line, but not enough to make motion 
commands fast.