Instead of handling broadcasts when the op is dispatched, handle them
when the op is first added to the world router.
This way we can better handle the case where an entity is deleted, as well
as make away with storage of perceptibles entities in the world router.
These properties didn't work out when we moved to a physics based world.
Instead we've introduced the properties "planted-offset" and "planted-scaled-offset".
These properties takes a float and specified vertical offset for planted entities.
Likewise with "planted-rotation" which specifies a rotation applied for planted entities.
"active-rotation" keeps track of any applied rotation.
Instead of directly setting position and orientation we've now
added a "transforms" property. This property contains zero or many
transformations. The result of these is what drives changes to an
entity's position and orientation.
By cleanly separate disrete transformations we can more easily undo
or alter them. This allows us to do things where the position or
orientation of an entity is affected by other properties, or other
entities.
The client protocol is intact. Changes to position and orientation is
still sent the same way, by specifying "pos" and "orientation". However,
these values will now not be written directly to corresponding values on
the entity. Instead they will first be written to the "transforms" property,
with the final values being a result of combining all data in the property.
Instead of the root entity always being the default one (for new
entities being created etc.) we now can specify another entity which is
the default one.
Don't keep the time in field, updated only at poll requests. Instead
calculate it when it's needed.
This fixes an old bug where all client movements were slightly
incorrect. The time was only recalculated at WorldRouter::poll calls. However,
when polling for IO the process waited up to 100 milliseconds. That
meant that any client received operation would get an on average 50
milliseconds offset in it's registered time. The result of this was that
most Move operations would be slightly incorrect, resulting in jerky
movement.
Since the queues weren't queues until after the destructor had run,
there was a risk of a spawn entity being deleted later on, leading to it
referencing invalid spawns since m_spawns weren't cleared.
