Introduce range iterator API

[Garry Yao]

There're many cases when we need to traverse the range from the start boundary node to the end boundary node, it's archiveable by the following codes:

var boundaryNodes = range.getBoundaryNodes();
		var firstNode = boundaryNodes.startNode;
		var lastNode = boundaryNodes.endNode.getNextSourceNode( true );
var node = firstNode.getNextSourceNode();
while( node )
{
	if ( node.getName() == 'span'  && currentNode.getAttribute( '_fck_bookmark' ) )
	{
		node = node.getNextSourceNode();
		continue;
	}
	// Processing logic...
	node = node.getNextSourceNode();
}

It's cumbersome due to at least two reasons:

1. The collapsed range problem reported at #3292;
2. It make code DUP at every plugin for the same logic;

It's necessary to introduce an API for this feature with dom iterator, which already holds a method for iterating over paragraphs. So after the API, other plugins should walking through the range as easy as using the iterator.

[Garry Yao]

Fred said he'll take care this ticket and refacting task after this fix will be handled by other new opening tickets.

[Frederico Caldeira Knabben]

Actually, the idea here is not really replicating the DOM Iterator, but the DOM Walker. I mean, making it possible to traverse all nodes available inside a range boundaries.

[Frederico Caldeira Knabben]

This patch brings an important change to the DOM Walker concept. It's now limited to a range boundaries, instead of a start/end nodes pair. It makes the walker much more powerful and easy to control.

The few points currently using the walker have been modified to reflect the changes. Several parts of the editor code can be rewritten, simplified and optimized after it.

I've left part of the code commented. Those are features we are not using right now in the editor, but we may need them in the future. As we're uncertain of it at this moment it's better to just leave them there.

[Frederico Caldeira Knabben]

This new patch adds the TC file.

[Garry Yao]

The patch is quite good, while there's two issues:

1. The default guard function logic on L48 and L62 of document boundary check is invalid.
2. The guard is not performed on specifically the boundary nodes, Please check the attached TC for this problem.
3. Some iteration state could be further cached instead of been calculated every iteration, e.g. L71-L82.
4. The walker should provide a 'reset' function to facilitate reusing of the walker on same range.

[Garry Yao]

Unit Test Case

[Garry Yao]

Unit Test Case

[Frederico Caldeira Knabben]

I've appended the new tests to the patch.

Replying to garry.yao:

1. Some iteration state could be further cached instead of been calculated every iteration, e.g. L71-L82.

I've considered that the guard function may change during the iteration. Let's leave it this way for now, just to be safe.

1. The walker should provide a 'reset' function to facilitate reusing of the walker on same range.

We don't need it into the code currently. It should be introduced if found needed later, but only if the recreation of the object is really hard to achieve.

[Garry Yao]

Another bug been identified at #3477, please check test_range_checkStartOfBlock.patch for it, though it's not related to the walker core.

[Garry Yao]

Replying to garry.yao:

Another bug been identified at #3477, please check test_range_checkStartOfBlock.patch for it, Let's fix the problem at dedicated ticket.

[Frederico Caldeira Knabben]

Fixed with [3463].

[Garry Yao]

Minor issue that document boundary check is invalid, see the attached test_walker_stopAtBody.patch.

[Garry Yao]

Unit Test Case

[Frederico Caldeira Knabben]

Garry's patch has been committed with [3465].

Please do not reopen tickets for related fixes, opening new tickets instead.