https://bugs.kde.org/show_bug.cgi?id=293314
He-he ;)

It happened due to the following:
1) Undo of removeLayer command added a layer and issued setDirty
   for this node
2) The scheduler calculated the walker for this update and put it
   into the queue
3) Undo of addLayer command removed one of the layers of the stack,
   leaving the queued walker in a very interesting state.

The point is that the walker stored a shared pointer to the removed
node, so it still had access to it and there were no crashes, but its
behavior was not obvious (read "unpredictable").

So I extended the meaning of the walker's checksum. Now it depends on
the graph sequence number as well, so the walker is recalculated when
he gets to know its data is outdated.

About Graph Sequence Number.

Now KisNodeGraphListener maintains an integer which shows current "version"
of the graph or its "sequence number". This integer is incremented on every
change made to the graph. So if you have some information about the graph
which was acquired while the sequence number was X and now you see the number
equals to Y, you should know your information is outdated and someone has
changed the graph since then.

BUG:293314