Introduce self-synchronizing objects

[akhenry]

Previously in our codebase "*" observers were needed in order to keep object instances in sync when a different instance of the object was mutated elsewhere in the application. Failure to do this could result in subtle bugs when code with a stale object model mutates that model, causing the stale model to be propagated out to other instances of the object.

A change was introduced by #3483 that obviates the need to manually keep domain object models synchronized.

Testing Notes

The fix was in the object mutation API, so testers should keep an eye out for any issues that occur during or after editing an object.
Testers should ensure that changes to an object are synchronized to other instances of the same object. eg:

• Renaming an object from the Browse Bar also renames it in the tree
• Renaming an object from the elements pool also renames it in the tree, and in the Browse Bar
• etc.

The LAD Table in particular should be tested, as a * observer was removed from here. This is the test ground for self-synchronizing objects. Testers should ensure that changes to other instances of the same object are reflected in LAD tables. eg.

• With a LAD table open, rename one of the objects in the elements pool and verify that the corresponding row in the table is also updated.

[davetsay]

verified*

*found flexible layout does not sync tree object when renaming from browse bar. working object types - condition set, display layout, telemetry table, tabs, notebook, folder. BUT... on retry it works with flexible layout, so not filed an issue for now.