changes to EntityTree simulation state management

This is some work that I started in my Bullet physics engine project when trying to simulate EntityItems in the physics engine.  I decided to move it to a non-physics branch and submit it as a prerequisite since the work here is doesn't actually use any physics yet.

In short this is some changes to how the **SimulationState** of an EntityItem is managed.

(1) I've combined the **Moving** and **Changing** states to be just **Moving**. 

(2) The EntityItem remembers which SimulationState category it has been put into, but the EntityTree manages all transitions of SimulationStates.

(3) EntityItems that are updated by network packets get funneled into a QSet in EntityTree that gets processed later.  Eventually this "changed set" will be used to relay any physics-relevant changes (position, velocity, shape) to the corresponding data structures inside the physics engine.
This is a cleaup of Octree::readElementData() that has the same behavior but with fewer CPU cycles:

(1) At line 294: The OctreeElement::addChildAtIndex() method does the right thing if the child already exists and returns a pointer to it (much like getChildAtIndex()), so we can just try to add it and capture the return value whether it was added not.

(2) At line 304: calling OctreeElement::setDirty() has no ill consequences if it is already dirty, and is not expensive, so there is no need to distinguish between the two cases of dirty or not, so we remove the check for it.

(3) At line 305: when we force the childElement to be dirty we might as well set this element to be dirty -- that way we don't have to bother saving the dirty bit to the side and checking it again later.

(4) At line 309: destinationElement will be marked dirty if any childElement was added earlier, so we check for that case here only once -- after the for loop is done.

Note: there appears to be the possibility that a **pre-existing** childElement could be marked dirty at line 305 which marks **this** element as dirty, but the **destinationElement** would NOT be marked dirty!  It seems odd to mark a child and grand-parent as dirty and not the parent.  But this is how the code worked from the start and I wasn't 100% sure this was not by design so I maintained this behavior.  Easy to fix if necessary.