[Scenario] Resolve latency on repeated Save All

In nasa/MCT-Plugins#80, repeated invocations of Save All resulted in progressively longer periods of latency during which the GUI was unresponsive. Identified and addressed some underlying causes:

* Issue was introduced by staleness listener added for #56. Specifically, the number of calls to this listener and the time it took per invocation were excessive (timeline merge operation measured to take 5-25 ms)
* Profiling revealed that many of the view-specific versions of activity components that had been created were not being made available for garbage collection. These were also potential origins of staleness notifications (each copy of each activity becomes stale). Investigation revealed this was due to references by way of change listeners not unregistered by Graph View, as well as by constraint systems that were not being cleared when the view was rebuilt.
* Multiple objects (activities, or the timeline itself) could be stale all at once, triggering multiple successive invocations of the staleness listener. To negate this, refactored such that this became a "one-use" listener - as the view is rebuilt from the database each time, all changes are effectively handled at the first invocation. A new listener is now instantiated and attached with each rebuild.
* Finally, staleness indicator was effectively creating a loop, as newly-allocated components were still receiving staleness notifications. While this may be a platform bug on some level, its impact in this case could be negated by verifying actual staleness before performing the view rebuild.