Excessive propertyChange events from MSAA slows down NVDA

[mdcurran]

Applications such as ones written using the Eclipse toolkit tend to fire an excessive amount of property changing MSAA events. events such as valueChange, nameChange, stateChange, descriptionChange etc are redundant if fired more than once in very quick succession on the same object as 1. neither speech or braille would be able to output them fast enough, and 2. the final event fired will still let NVDA know that the property changed on that object.
Currently NVDA processes all events, in fact, it queues them so that it will not miss one at all, even if it takes a while to process a previous one.
A suggestion would be that IAccessibleHandler limit these change events, to perhaps one per 200 ms from a given window,objectID,childID object identifier.
This would mean that when an event is received, it must cache the eventID,window,objectID,childID 4-tuple in a dictionary, along with the time the event was last fired.
IAccessibleHandler.pumpAll would search the dictionary on each NVDA core cycle, and find any events who were recorded 200 ms or more ago. It fires these events with eventHandler and deletes the event from the dictionary.
Note this idea must only be applied to property change events, no other ones. It may also be an idea in future to allow the time threshold to be set for particular windowClasses and event IDs, but its probably not that important for now.

[mdcurran]

Fixed in r1632. Also event_reorder is also limited by the propertyChange event limiting code, as reorder is in some ways rather like a property change anyway. Also the limit is currently at 100 ms, not 200 ms as 100 ms seems more than enough limiting. I can personally see performance improvements already in NVDA, in many places, not just in Eclipse applications.