pull entity simulation out of EntityTree

The EntityTree::update() method would call EntityItem::update() on each entity and would also maintain a list of Moving and Static entities.  That kind of work falls under the domain of a physics engine (when available) so this is an effort to make it easier to replace the default simple (velocity + gravity) extrapolation simulation with a more elaborate physics engine.

To this end the movement of entities has been pulled out of EntityTree and given to an EntitySimulation, of which SimpleEntitySimulation is an implementation.  The EntityTree gets an optional pointer to an EntitySimulation.

The interface also does some simple collision detection in the EntityCollisionSystem class.  This class has been moved to the interface codebase, and now derives from SimpleEntitySimulation.  So the interface Application class connects its _entityCollisionSystem up to its EntityTree.

The EntityServer and EntityTreeHeadlessViewer classes also get simulations so that they can move entities around.
I guess this is a simple matter of fewer relatively "common theme" libraries vs more "minimal dependency" libraries. I am ok with whichever approach we pick, but I think it's really six one way, half a dozen the other. Since modern linkers don't include unused code modules we can be confident that users of the library (e.g. EnttityServer) that don't use code from some of the object files, will not have those object files linked into them.

We know we need to get an implementation of "true collisions" working in an domain when no one is logged into it. This is a well known "bug"/"design flaw" in our current system. I believe that MVP requires that we solve this problem. We've already had multiple alpha complaints about the fact that collisions stop happening when no one is logged into view the domain.

So, the fix for this will be to implement an AC that handles observing the domain and implementing collisions. As our architecture works today... all the AC types live in the assignment-client executable. So all ACs will end up having the "physics" code we need.

So this means that both targets that have entities in them: Interface and assignment-client, will both have some collision code in them. So how does it simplify things to move collision logic out of the Entities library? We certainly could make an "entities-collision" library... but all targets that link to entities will also end up linking to the entity-collisions library... what have we saved by making it a separate library?