Physical Terse Updates fixed

Yay, It turns out that there were two bugs with regards to terse updates.    The first one was in SceneObjectPart.SendScheduledUpdates().    In some cases, it didn't clear the UpdateSchedule using ClearUpdateSchedule().   This means that objects that failed the duplicate test were never getting the m_updateFlag set back to zero.       In this state, the call to ScheduleTerseUpdate would fail because of the m_updateFlag < 1 test.  It would skip entirely over the code that schedules terse updates.

The second update was adding:

Velocity.ApproxEquals(Vector3.Zero, VELOCITY_TOLERANCE) ||

to the duplicate check in SendScheduledUpdates().   This ensures that Updates with the velocity <0,0,0> get sent.    Without that, the Zero velocity vector isn't guarenteed to get out.    Thirdly, I added a check in the ODEPrim.Velocity Getter.  If _ZeroFlag, then return <0,0,0> for the velocity.   If _zeroFlag is set, it has come to a rest regardless of what the tiny amount of velocity it might have.   Here, I think the averaging of the previous velocities was working against us.     "returnVelocity.X = (m_lastVelocity.X + _velocity.X)/2;"   will return a higher velocity when the object is stopped then it should for the last update with a zero velocity.   This causes the object to keep moving.    The averaging was put in place to make object motion appear more smooth.