V3: Simplify domWalker

[Frederico Caldeira Knabben]

The current domWalker implementation is much more complex than it needs to be. It's using our event system to control its execution even internally, with no benefit from it. It should instead use direct function calls, like onDown, onUp and onSibling.

The event system is to be used if we know we may have more than one, or an unknonwn number of listeners to the events. It's there to give flexibility, not just because it's nice to code with it.

If instead we know we'll just have a single listener, we can safely do direct function calls. This eliminates the overhead coming from the even system, which definitely impacts on performance.

[Garry Yao]

The patch remaining all existing interfaces while use direct function calls for guard control.

[Frederico Caldeira Knabben]

While working on #3299, I've faced a limitation in the domWalker system. As said in this ticket the domWalker is far too complex for what we really need. It's also in part, a duplication of node::getNextSourceNode and node::getPreviousSourceNode.

I've analyzed the parts of the code that use the domWalker, and I've found out that it's event system is mostly not needed. It's useful for its own code only.

So, let's KISS... I've written a new walker class from scratch.

[Frederico Caldeira Knabben]

To make things less risk, I'm not touching the original domWalker for now. I'm instead introducing a new class: CKEDITOR.dom.walker. In this way we can fist introduce this new class, and them replace the code using domWalker on dedicated tickets.

This new walker class, other than simplifying the code, adds a few features to the original implementation. It also enhances the node::getNextSourceNode and node::getPreviousSourceNode functions by adding the guard feature to them.

This class will be used by #3299, so the review can happen simultaneously.

[Frederico Caldeira Knabben]

Fixed with [3351].

#3304 has been opened to deal with the remaining domWalker stuff.